Part I: The Disciplines

What is a discipline? A discipline is a set of rules that are composed of two parts: the essential part and the arbitrary part. The essential part is what gives the discipline its power; it is the reason that the discipline exists. The arbitrary part is what gives the discipline its form and substance. The discipline cannot exist without the arbitrary part.

For example, surgeons wash their hands before surgery. If you were to watch, you would see that the handwashing has a very particular form to it. The surgeon does not wash hands by simply soaping them under running water, as you and I might do. Rather, the surgeon follows a ritualized discipline of handwashing. One such routine I have seen is, in part, as follows:

• Use the proper soap.

• Use the appropriate brush.

• For each finger, use

• Ten strokes across the top.

• Ten strokes across the left side.

• Ten strokes across the underside.

• Ten strokes across the right side.

• Ten strokes across the nail.

• And so on.

The essential part of the discipline should be obvious. The surgeon’s hands must be made very clean. But did you notice the arbitrary part? Why ten strokes instead of eight or twelve? Why divide the finger into five sections? Why not three or seven sections?

That’s all arbitrary. There is no real reason for those numbers other than that they were deemed to be sufficient.

In this book, we study five disciplines of software craftsmanship. Some of these disciplines are five decades old. Some are just two decades old. But all have shown their usefulness over those decades. Without them, the very notion of software-as-a-craft would be virtually unthinkable.

Each of these disciplines has its own essential and arbitrary elements. As you read, you may find your mind objecting to one or more of the disciplines. If this happens, be aware of whether the objection is about the essential elements of the disciplines or just the arbitrary elements. Don’t allow yourself to be misdirected by the arbitrary elements. Keep your focus on the essential elements. Once you have internalized the essence of each discipline, the arbitrary form will be likely diminish in importance.

For example, in 1861, Ignaz Semmelweis published his findings for applying the discipline of handwashing for doctors. The results of his research were astounding. He was able to show that when doctors thoroughly washed their hands in chlorine bleach before examining pregnant women, the death rates of those women from subsequent sepsis dropped from one in ten to virtually zero.

But the doctors of the day did not separate the essence from the arbitrary when reviewing Semmelweis’s proposed discipline. The chlorine bleach was the arbitrary part. The washing was the essence. They were repelled by the inconvenience of washing with bleach, and so they rejected the evidence of the essential nature of handwashing.

It was many decades before doctors started actually washing their hands.

Extreme Programming

In 1970, Winston Royce published the paper that drove the waterfall development process into the mainstream. It took almost 30 years to undo that mistake.

By 1995, software experts started considering a different, more incremental approach. Processes such as Scrum, feature-driven development (FDD), dynamic systems development method (DSDM), and the Crystal methodologies were presented. But little changed in the industry at large.

Then, in 1999, Kent Beck published the book Extreme Programming Explained (Addison-Wesley). Extreme Programming (XP) built upon the ideas in those previous processes but added something new. XP added engineering practices.

Enthusiasm grew exponentially for XP between 1999 and 2001. It was this enthusiasm that spawned and drove the Agile revolution. To this day, XP remains the best defined and most complete of all the Agile methods. The engineering practices at its core are the focus of this section on disciplines.

The Circle of Life

In Figure I.1, you see Ron Jeffries’ Circle of Life, which shows the practices of XP. The disciplines that we cover in this book are the four in the center and the one on the far left.

Figure I.1 The Circle of Life: The practices of XP

The four in the center are the engineering practices of XP: test-driven development (TDD), refactoring, simple design, and pairing (which we shall call collaborative programming). The practice at the far left, acceptance tests, is the most technical and engineering focused of the business practices of XP. These five practices are among the foundational disciplines of software craftsmanship.

Test-Driven Development

TDD is the lynchpin discipline. Without it, the other disciplines are either impossible or impotent. For that reason, the two upcoming sections describing TDD represent nearly half the pages of this book and are intensely technical. This organization may seem unbalanced. Indeed, it feels that way to me too, and I struggled with what to do about that. My conclusion, however, is that the imbalance is a reaction to the corresponding imbalance within our industry. Too few programmers know this discipline well.

TDD is the discipline that governs the way a programmer works on a second-by-second basis. It is neither an up-front discipline nor an after-the-fact discipline. TDD is in-process and in-your-face. There is no way to do partial TDD; it is an all-or-nothing discipline.

The essence of the TDD discipline is very simple. Small cycles and tests come first. Tests come first in everything. Tests are written first. Tests are cleaned up first. In all activities, tests come first. And all activities are broken down into the tiniest of cycles.

Cycle times are measured in seconds, not minutes. They are measured in characters, not lines. The feedback loop is closed almost literally as soon as it is opened.

The goal of TDD is to create a test suite that you would trust with your life. If the test suite passes, you should feel safe to deploy the code.

Of all the disciplines, TDD is the most onerous and the most complex. It is onerous because it dominates everything. It is the first and last thing you think about. It is the constraint that lays thick over everything you do. It is the governor that keeps the pace steady regardless of pressure and environmental stresses.

TDD is complex because code is complex. For each shape or form of code, there is a corresponding shape or form of TDD. TDD is complex because the tests must be designed to fit the code without being coupled to the code and must cover almost everything yet still execute in seconds. TDD is an elaborate and complex skill that is very hard won but is immeasurably rewarding.

Refactoring

Refactoring is the discipline that allows us to write clean code. Refactoring is difficult, if not impossible, without TDD.¹ Therefore, writing clean code is just as difficult or impossible without TDD.

¹ There may be other disciplines that could support refactoring as well as TDD. Kent Beck’s test && commit || revert is a possibility. At the time of this writing, however, it has not enjoyed a high degree of adoption and remains more of an academic curiosity.

Refactoring is the discipline by which we manipulate poorly structured code into code with a better structure—without affecting behavior. That last part is critical. By guaranteeing that the behavior of the code is unaffected, the improvements in structure are guaranteed to be safe.

The reason we don’t clean up code—the reason that software systems rot over time—is that we are afraid that cleaning the code will break the behavior. But if we have a way to clean up code that we know is safe, then we will clean up the code, and our systems will not rot.

How do we guarantee that our improvements do not affect behavior? We have the tests from TDD.

Refactoring is also a complex discipline because there are many ways to create poorly structured code. Thus, there are many strategies for cleaning up that code. Moreover, each of those strategies must fit frictionlessly and concurrently into the TDD test-first cycle. Indeed, these two disciplines are so deeply intertwined that they are virtually inseparable. It is almost impossible to refactor without TDD, and it is virtually impossible to practice TDD without practicing refactoring.

Simple Design

Life on Earth could be described in terms of layers. At the top is ecology, the study of systems of living things. Below that is physiology, the study life’s internal mechanisms. The next layer down might be microbiology, the study of cells, nucleic acids, proteins, and other macromolecular systems. Those are in turn described by the science of chemistry, which in turn is described by quantum mechanics.

Extending that analogy to programming, if TDD is the quantum mechanics of programming, then refactoring is the chemistry and simple design is the microbiology. Continuing that analogy, SOLID principles, object-oriented design, and functional programming are the physiology, and architecture is the ecology of programming.

Simple design is almost impossible without refactoring. Indeed, it is the end goal of refactoring, and refactoring is the only practical means to achieve that goal. That goal is the production of simple atomic granules of design that fit well into the larger structures of programs, systems, and applications.

Simple design is not a complex discipline. It is driven by four very simple rules. However, unlike TDD and refactoring, simple design is an imprecise discipline. It relies on judgment and experience. Done well, it is the first indication that separates an apprentice who knows the rules from a journeyman who understands the principles. It is the beginning of what Michael Feathers has called design sense.

Collaborative Programming

Collaborative programming is the discipline and the art of working together in a software team. It includes subdisciplines such as pair programming, mob programming, code reviews, and brainstorms. Collaborative programming involves everyone on the team, programmers and nonprogrammers alike. It is the primary means by which we share knowledge, assure consistency, and gel the team into a functioning whole.

Of all the disciplines, collaborative programming is the least technical and the least prescriptive. Nevertheless, it may be the most important of the five disciplines, because the building of an effective team is both a rare and precious thing.

Acceptance Tests

Acceptance testing is the discipline that ties the software development team to the business. The business purpose is the specification of the desired behaviors of the system. Those behaviors are encoded into tests. If those tests pass, the system behaves as specified.

The tests must be readable and writeable by representatives of the business. It is by writing and reading these tests and seeing them pass that the business knows what the software does and that it does what the business needs it to do.