Writing code for software solutions involves solving many small problems, and the small solutions are then aggregated to create a solution to a larger problem. Once all the lines of code work together, a developer can sometimes slowly back off and hope that nothing will upset the balance that currently makes the software solution work. However, the problems arise immediately when the requirements of the software change, and we have to dive into thousands of lines of code and understand what needs to be changed and how the change should not break something that we have already built. This is the observation that led the Extreme Programming movement, back in the 1990s, to emphasize the importance of keeping the cost of a further change to the system constant, instead of increasing with the number of features in the system.

It has been shown that some behaviors keep down the cost of further developing systems and they are relatively generally applicable as engineering principles in product development. It’s about using scientific thinking by starting by setting your expectations about what, for example, a small piece of code should do. We construct a test that can evaluate whether the code is correct, even before we have even written the code. Then we can experiment with solutions and directly find out if the solution actually meets our expectations that we set in the test.

It is sometimes called “shifting left” in that potential problems and incorrect assumptions are discovered earlier on the timeline, further to the left on the timeline.

This is a way of thinking that extends beyond developing software. For example, the car manufacturer Tesla constructed a robot that could evaluate whether a seat fits, even before they even started designing their seat. Once they had a quick and efficient way to know if the seat met all the requirements such as softness, handling odors, stains, etc., they could iterate on a good seat design much faster. Today, they are considered to have one of the world’s most comfortable seats to sit in for a long ride.

Because the challenge lies in the question, how do I know that my solution still meets all the requirements I have for it when I make a change to the solution? Then I need a cheap way to find out that everything is still working. This almost always means that I need an automated flow to test both low-level assumptions, that each small component does what it’s supposed to, and that the parts and whole of the product work as they should. Building that capability costs initially, and then a little over time, but is the only way to avoid that the total cost of a change spiraling up and thus making the product almost impossible to change.

In software, we build so-called continuous deliver pipelines which are computers that run scripts to try to build software and run tests on the new version to see that it still works. Of course, that requires all developers to write tests before writing code, just like we talked about above. Otherwise, the pipeline has nothing to test. It requires that we agree on how we do things in our teams, that we hold each other accountable by, for example, looking at each other’s contributions to the code before it is allowed to move forward in the process. Make sure it follows the standard we set together, that there are tests, etc. Creating high-quality systems, whether they consist of software, hardware or a combination, requires discipline and we need to help each other maintain that discipline. It cannot be added from the outside or afterwards, quality needs to be built in by those who build, when they build. Consider a homeowner that hires a handyman to add a new door to an existing wall. It is little consolation for the homeowner if an inspector afterwards finds that the wall was cut in the wrong place because the craftsman did not use a ruler before starting the work.

What this means is different for different domains? In SAFe, the Built-In Quality article now describes in more detail how we can use these quality-enhancing techniques in various areas ranging from business to cyber-physical systems. The same basis still applies, each domain has its more applied pieces of the puzzle that provide an input to further work.

This mindset runs deep and may require us to question long-held assumptions about “how we do things around here.” An important control question could be: “if we could make a valuable change in our production within a few hours, what kind of demands would that place on our working methods while maintaining good quality for our customers?”

Fredrik Viljesjö