The Essentials of Modern Software Engineering. Ivar Jacobson

explain the iterative lifecycle methods, structured methods, component methods, and agile methods, as well as their characteristics;

      • give examples of some practices (e.g., self-organizing teams, pair programming, and daily standups as examples of agile practices);

      • explain the “method prison” issue discussed in the chapter; and

      • explain the SEMAT initiative and the motivation behind the Essence standard.

      Again we point to additional reading, exercises, and further material at www.software-engineering-essentialized.com.

      1. http://spectrum.ieee.org/riskfactor/computing/it/it-hiccups-of-the-week

      2. http://spectrum.ieee.org/riskfactor/computing/it/new-zealand-police-admits-sending-20-000-traffic-tickets-to-the-wrong-motorists

      3. http://spectrum.ieee.org/riskfactor/computing/it/it-hiccups-of-the-week-university-of-wisconsin-loses-another-11-million-in-payroll-glitches

      4. Wikipedia: “A paradigm shift, as identified by American physicist and philosopher Thomas Kuhn, is a fundamental change in the basic concepts and experimental practices of a scientific discipline.”

      5. From Wikipedia: “The metaphor of dwarfs standing on the shoulders of giants … expresses the meaning of ‘discovering truth by building on previous discoveries’.”

      6. https://www.infoq.com/news/2014/01/IDC-software-developers

      3

       Essence in a Nutshell

      In this chapter we present key ideas resulting in Essence as a common ground for all software engineering methods. Basic concepts of Essence, the notion of a method and the architecture of Essence are introduced. In particular, this chapter introduces and explains

      • the key ideas resulting in Essence and why they are important for software engineering;

      • the concept of composition as a way to combine practices to form a method to guide a development endeavor;

      • the common ground Essence as consisting of a language and a kernel of essential elements;

      • the concepts of practices and methods built of top of Essence forming a method architecture; and

      • the concept of cards as a means to give the abstract elements of Essence an attractive and tangible user experience.

      This chapter shows that the main idea behind Essence is to focus on the most important things to think about when developing software (focus on the essentials only).

      Essence became a standard in 2014 as a response to “the craziest thing in the world” presented in Chapters 1 and 2.

      In this chapter, we will present some key ideas used as input when designing Essence. We will also separately motivate each idea and describe how it has been realized with Essence.

3.1 The Ideas Essence relies on the following insights.

      • Methods are compositions of practices.

      ■ There are a huge number of methods (guesstimated to be > 100,000) in the world, some of which are recognized and have a large user base.

      ■ There are only a few hundred reusable practices in the world. With n practices the number of theoretically possible combinations of these practices can quickly grow very large.

      • There is a common ground, or a kernel, shared among all these methods and practices.

      • Focus on the essentials is needed when providing guidelines for a method or practice.

      • Providing an engaging user experience is possible when teaching and learning methods and practices.

3.2 Methods Are Compositions of Practices

      As explained in Chapter 2, a method is created with the intention to guide the software development team(s) through everything they need to do during the development process: that is, giving them all the practices they need. A practice is like a mini-method in that it guides a team in how to carry out one particular thing in their work. For instance, “requirements management” is a potential practice dealing with what a software system should do. It is obviously not all you need to do when you develop software; you need many other such practices, for instance, “design, implement, and test,” “organize your team,” “perform project management,” etc. For small endeavors, it is not uncommon that you need a dozen such mini-methods/practices.

      Because a method is attempting to give complete guidance for the work, it relies on a composition of practices. This is an operation merging two or more practices to form the method. Such a composition operation has to be defined mathematically in order to be unambiguous and precise. It has to be specified by a method expert with the objective to resolve potential overlaps and conflicts among the practices, if there are any. Usually most practices can be composed easily by setting them side by side because there are no overlaps and conflicts, but in some cases, these have to be taken care of.

      This is because, while practices are separate, they are not independent. They are not like components that have interfaces over which communication/inter-operation will happen. They also share elements, so let us briefly look at what these might be. Inside a practice are, for instance, guidelines for activities that a user (e.g., a developer) is supposed to perform, and guidelines for work products (e.g., components) that a user is expected to produce. Although two practices may share the same work product, they contribute separate guidelines to this work product, and composing these two practices, resolving potential overlaps and conflicts, will require that you specify how the contributions must be combined in a meaningful and constructive way.

      However, not just methods are compositions, but also practices can be compositions of smaller practices. Scrum, for instance, can be seen as a composition of three smaller practices: Daily Standup, Backlog-Driven Development, and Retrospective. (We will discuss these later when we come to Scrum in Part III.)

      We will come back later to compositions when we have more details about practices in our knowledge bag. (If you want to have a peek into more on compositions now, take a look at Chapter 19.)

      What eventually becomes a method or a practice is just a practical decision. To reiterate, a method is closer to the complete guidance you need whereas a practice (composed or not) is just one aspect (or several) of what you need to guide the team(s) to deal with all the “things” they need to deal with when developing software. An individual can create one or a few practices based on experience, but a method is always too big to be created by one individual without “borrowing” practices from others. We say “borrowing” within quotes, because it is an act without consent of the originator. Practices are successful because of the knowledge they provide, whereas methods are usually branded (like RUP, SAFe, DAD, Nexus, Less) and success is more about great marketing than about knowledge being provided.

      When we say that a practice guides a team, we mean it is described one way or another to indicate what to do. How explicit a practice should be,