At the beginning of this book, we looked at the birth of Agile and what provoked this movement. In Chapter 1, The Software Industry and the Agile Manifesto, we discussed how, in an attempt to correct our inability to bring projects in on time and budget, we sought to get more precise in our predictions.

It was felt that if other engineering disciplines such as civil engineering were able to be more precise with their process, then so could software engineering.

However, the reality is that we don't build software like we construct bridges or buildings or hardware. With all of those physical things, by the time we get to the actual construction phase, we've already created the design schematics. The construction phase is an endeavor in logistics based on assembling the different components in the right order.

As Neal Ford, software architect at Thoughtworks, describes it, with software, the code itself is our design. Our build phase in software is when we compile/interpret the program code so it can be run.  Our program's concrete outputs are the actual results of the design, in the form of pixels illuminated on the screen or messages sent over the ether. That is the tangible result of "building" the design we've written in our software's code.

So, if we're to get better at producing the right output, we have to get better at "designing" our code. Practices we've discussed so far in this chapter will certainly help us evolve our design safely and efficiently.

For example, TDD creates a test harness based on our software's specifications. This allows us to design our software to the specifications prescribed in our requirements (User Stories, their associated acceptance criteria, and possible test scenarios).

TDD's red/green/refactor approach to software development helps us ensure that intended behavior will continue to work as we begin to make changes to our software's underlying structure, for example, improving its scalability.