Essence and Problem Solving Blog

January 30, 2021

Teaching the software development life cycle to high school students: Don’t forget to include why they should care

Filed under: Essence and Problem Solving — pemcmahon @ 11:56 pm
Tags: ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version, click on the link and scroll down to where you can select the podcast.   

Blog Text Starts Here:

I recently received the following challenge from a high school teacher. He said,

“The goal is to code the Software Development Life Cycle (SDLC) using the Essence language. The result should be easy to understand for anyone, especially those NOT exposed to Essence. The general idea is to Essentialize something like Figure 1. My target is 16 year old students, or people who just started programming on their own.”   

                                                                                        Figure 1 SDLC

Let me start by saying that when I was in high school I wasn’t a great student. One reason was because I didn’t see what good much of what I was being taught was, so I wasn’t motivated to learn.  I almost failed ninth grade algebra.  I had no idea what the x’s and y’s had to do with the real world I lived in.  It would have been nice if this had been explained to me back then, but it wasn’t.  I start with this story because it affects the way I approach any challenge related to teaching students anything.  You have to first give them a reason to care.

Given this background, let me share how I would tackle this challenge today.

I would start by explaining to the students what the diagram in Figure 1 isn’t intended to tell them and then explain at least one practical use of the diagram they might care about.   I would focus first on what this diagram isn’t intended for because knowing what isn’t intended may help eliminate common mistakes. 

I would do this by saying something like:

“First, please don’t try to read too much into this diagram. I am stressing this point first because historically reading these kinds of diagrams too literally has led many software endeavors down troubled paths.   Specifically, the figure is not meant to imply a strict ordering of the software development activities identified on the diagram, nor is it intended to say anything about how to go about conducting the software development activities highlighted.” 

Next, I would explain what the diagram is trying to communicate and I would give a practical example that demonstrates why software developers should care.

I would do this by saying something like:

“The Software Development Life Cycle (SDLC), as depicted in Figure 1, is a simplified way to represent software activities conducted by a team. A team includes all the software developers involved in a software endeavor, as well as at least a few potential users of the software who can represent the views of the wider user community.  The value of an SDLC is that it helps anyone see the big picture, but what you don’t see on this diagram are essentials for software development success that underlie each of the activities identified and that is what you should care most about if you want to be a successful software developer.”

I would then give a few examples of those essentials by saying something like:

“Examples of essentials for success include principles, values, key practices and constraints. An example of a “principle” is Rapid feedback which could mean your team agrees to work in short cycles that include constant team and user communication. An example of a “value” is Courage, which could mean your team agrees to go as fast as they can, while also having the courage to slow down and share with their teammates anything that bothers them that they can’t solve on their own.  An example of a “ key practice” could be to develop tests before developing the code. An example of a “constraint” could be an agreement that there will be only three team members available to complete the entire software system.” 

I would then explain that principles, values, key practices and constraints must be agreed to by all software developers on the team, the software user representatives, and anyone else who your team depends on for help.   And here I would add, just for emphasis, when we look back at troubled software endeavors we often find that the root of the trouble can be traced back to a failure to reach agreement—or to take serious that agreement– on at least one of these essentials for success. 

I would also explain that principles, values, key practices and constraints can– and often do–  change on each software development endeavor.  In other words, you can’t learn just one way to develop good software and expect that the exact same way will work on all your future software endeavors.  

At this point I would slow down and tell them that in the future when they look at this diagram I suggest they try to recall what I am about to say about the essentials underlying each of the 6 activities highlighted on the diagram.  I would then explain the diagram to them in the following way:

Activity 1: Planning Essentials

On all software endeavors there is always work to be done by the team.  To be successful that work must be sufficiently broken down so the team can estimate their effort and commit to a credible (believable) plan.  

Activity 2: Analysis Essentials

When breaking the work down questions will arise that must be investigated and decisions made related to building new software, buying existing software, or reusing parts of existing software. 

Activity 3: Design Essentials

When breaking the work down decisions must to be made regarding hardware platforms (e.g. the computer or smartphone the software will run on), technologies used (e.g. programming languages), and interfacing mechanisms(e.g. how the software will communicateoutside its platform, such as cloud services). 

Activity 4: Implementation Essentials

The system must be tested and demonstrated, first in small pieces, based on the agreed to credible plan.

Activity 5: Testing and Integration Essentials

The small tested and demonstrated pieces must be integrated (combined) together, based on the agreed to credible plan to make sure the system as a whole is fit-for-purpose.

Activity 6: Maintenance Essentials

After the system has been accepted by the users as fit-for-purpose, acceptable defect levels must be maintained and agreed service levels supported.  This means that all defects don’t necessarily have to be fixed, but the critical ones– in the eyes of the users and the team– must be adequately addressed.

I would then point out to the students that the six essentials, as just described, usually occur iteratively (repetitively) within feedback cycles.  The details of these feedback cycles depend on the way of working that must be agreed to by the team as well as those who use or can affect the software system.

Now, let me say a little more about the approach I have just suggested in this blog to explain the SDLC  to high school students. 

First, I chose my words carefully.  The description provided above focusing on essentials underlying each of the six activities can be referred to as an “essentialized” description of the SDLC.  Essentialized means it uses the Essence language to communicate essentials.  

Specifically, information provided on principles, values, key practices and constraints can be found in the Essence Stakeholder, Team and Way of Working Alphas.  When you hear the word “alpha” just think of the important things we work with and want to keep healthy for software success.   Other italicized words in this blog can be found in Essence checklists.  Consistent with the Essence language, the term software system as used in the above description includes both the software and the hardware required to run the software.  This is because software without hardware provides no value.  And value is critical because Essence is a practical framework. It is based on what experienced practitioners have found is essential for success. 

The description of an SDLC provided in this blog is an example of using Essence in “stealth mode.”  For more information on Essence and the rationale for using Essence in “stealth mode” refer to [ 1, 2, 3, 4].

I would like to end this blog by providing a little rationale for the approach I have suggested to teaching the SDLC to high school students.

Using an “essentialized” description to teach high school students the Software Development Lifecycle can help our next generation of software developers avoid common mistakes of the past, and help them maintain awareness of the most important things to pay attention to for success when developing software.

As a final point, you might be wondering why it matters exactly what words, or phrases, we use when talking about software development.  The simple answer is because words matter.  Words are how we communicate, but they can easily be misunderstood.  The words, and phrases used in the Essence language were carefully chosen with the goal to minimize miscommunication and misunderstanding, while highlighting the essentials for success.

Feedback is encouraged.

[1] For more information on the background, rationale, and thinking behind Essence refer to

[2] For more information on case studies and practical uses of the Essence framework refer to

[3] For more information on Essence and Essence in Use refer to

[4] For training in using Essence in stealth model and as a critical thinking tool refer to

Blog at