Why Nine Practices?

My new book, Beyond Legacy Code, Nine Practices to Extend the Life (and Value) of your Software is out. I guess one obvious question is: Why nine practices?

I wanted to organize the book around core practices because this would let readers jump around in the text and focus on the practices that are most important to them. So far in the feedback I’ve seen, this format works pretty well.

They say you can remember about seven things, plus or minus two, so nine is the most that most people can remember. Also, nine practices filled about as much room as I had in the book!

I always try to reduce knowledge to the smallest serving I can. There’s a lot developers have to keep in mind when building software, so I tried to focus on just the things that provide the highest value and from which we can infer other good ideas.

The nine practices that I call out in my book aren’t the most popular or well-known software development practices but they are the highest benefit practices. These are the ones that will make the biggest difference for software developers because after all, software development is a technical activity. The Scrum ceremonies like standup meetings and retrospectives are valuable, but in my opinion are not among the most essential practices for building maintainable software.

I’m happy that Scrum and Agile have become so popular, but companies are not adopting all of the Agile practices and are leaving out some very important aspects of Agile software development, so I wanted to set the record straight and discuss the key practices that are most valuable for building software.

I’ve provided an overview of these practices elsewhere so I won’t do that again here. I just want to point out that it’s the last five of the practices that are most important. Starting with CLEAN code, writing the test first, specifying behaviors with tests, implementing the design last, and refactoring legacy code are all technical practices. All of them require a great deal of discipline.

It’s true that in Agile we don’t do a lot of upfront design but that doesn’t mean that we don’t do design at all. In Agile, we do emergent design, which means we design as we go. Instead of devoting the first 20% of a project to design, we devote the entire project to design and then we implement that design little by little in code as we go.

This is not just a reorganization of priorities but a fundamental shift in how we build software. This shift engages developers to make the right decisions in the moment as we’re building code and the end result is a far better product than we could achieve any other way. It’s only through incremental construction that we discover the capabilities to make code extensible and flexible. It never comes up in a traditional Waterfall project when we build to releases, because we don’t return to our code very often, and we’re not incentivized to build code that’s maintainable. As a result, code quality stinks in traditional Waterfall projects.

If we build software with the same poor code quality in an Agile environment, we have still doomed our project to failure. People think Agile is an undisciplined shoot-from-the-hip kind of approach to building software, and that’s simply not true. In fact just the opposite is true. Agile requires a great deal of discipline and a strong focus on code quality. Instead of spending time on checks and balances, Agile developers focus on building quality into their code. But just removing the checks and balances without adding the focus on quality is a recipe for disaster.

You have been warned.