When building software over long release cycles, developers may not see code run until months after it’s written. They might build a “testing harness” so their code can be reached in a debugger (software that lets you detect bugs in other software) and stepped through one statement at a time, but this is not the same as running the code in the way it’s meant to be run in the context of the whole system.
This is one of the main problems with batching features up into releases. It may make a lot of intuitive sense to batch things up. This is how we construct things. If you’re building a house you want to get everything you need to build the foundation over to the job site so you won’t have to stop that step waiting for more concrete, or whatever. Then you want to drop all the lumber so you aren’t paying for carpenters to sit around waiting for a few more ceiling beams, and so on.
This is one of the main differences between virtual things and physical things. As it turns out, batching things up doesn’t work well in the virtual space.
And it’s not just that batching is inefficient—and we’re going to talk about the inefficiencies as we start to look at the cadence of different release cycles—it forces us to build things that are unchangeable. This is far more subtle, but vitally important.
Only when you build things incrementally can you put the joints in to allow you to expand it later. You don’t even think about it when you optimize for building software in releases. In the Waterfall world it’s just never a priority and never an issue. No one builds a house with later room additions in mind. You build the house the blueprints call for. And how often does someone add a room addition to a house? Compare that to how often a new feature is added to software.
There’s a difference between a recipe and a formula. You can make, say, marinara sauce from a recipe and it will taste the same as the marinara sauce made by someone else from the same recipe, but only if both cooks follow that recipe in exacting detail. But if one cook adds a little more pepper, and someone else uses more basil and less oregano, it’s still marinara sauce. On the other hand, if two bakers are making bread and one alters the balance of water, flour, and yeast, that bread will fail to rise—it’ll be ruined. Baking bread requires a formula.
We have to start seeing software development not as formulas to be followed in exact detail, but as recipes open to the creative interpretation of individual chefs to be adjusted according to the specific situation.
Programming is not a “paint by the numbers” kind of activity except in the most mundane types of tasks. Many tasks require breaking new ground and moving into uncharted territories. Software development has many contraindications where the “right” approach in one situation is the wrong approach in another situation.
This sense of stepping into the unknown tends to force traditional Waterfall processes to get increasingly more complex in an effort to predict and moderate the parade of unknowns. But making something more complex doesn’t automatically make it better, and this can quickly get out of hand.
“It’s my job to get through this as quickly as I can and do my best to hit all the features I’ve been asked for, but the QA team is the angel on my shoulder so I can afford to be sloppy, to just take a wild stab at it because my job is to create the rough draft and then I have this ‘coauthor’ who’s going to be there to perfect it.”
How many times have you, as a software developer, thought or said that—or as a manager, heard it said? But the QA team really isn’t a software developer’s “coauthor.” All QA can say is, “Go back and try it again. Oh, and by the way, your time has run out.”
How could we possibly win when we set ourselves up like this? And yet this is business as usual, and is a big problem because it encourages developers to not pay attention to what they’re doing in the moment.
This problem isn’t limited to just Waterfall development. The majority of software development projects still have a separate QA effort with manual parts that take days or even weeks to validate release candidates.
Stimulus and response have to be as close together as possible in order for us to change our habits. When developers don’t see the consequences of our actions until months later, it doesn’t properly register. It’s as if we’re living by the motto:
It’s not my job to find the errors; it’s my job to create them.
Like Waterfall, other popular project management methodologies like Six Sigma and Total Quality Management, which were highly successful in providing consistency and quality of manufactured goods, have significant problems when applied to software. Ironically, we spend so much time focusing on the checks and balances of the methodology that we don’t have any time to focus on putting quality into the product.
Traditional software development practices, with a focus on predicting the future and pre-measuring workflow, end up forcing developers and managers alike to find ways around the intrusive nature of the process in an effort to simply get their work done.