Would you rather cultivate good code or try to force good code to happen through control? Control like RACI matrices, tracking bug metrics, code review processes, gated check-ins, gated deploys, style guides, and code freezes?
The answer isn’t simple.
‘Cultivate’ sounds wishy-washy, and it certainly doesn’t sound like something you could take to the VPE or the CTO (and if you’re the CTO, you probably wouldn’t be caught dead saying “cultivate” to the CEO or a board member), but if you start to say RACI, bug metrics, gated check-ins, and change-control management to line developers, there’s a chance they’ll either enthuastically support the idea or internally cringe.
I count myself in the ‘internally cringe’ group; not because I believe those activities are without value (they do have value, even if it’s to manage up other humans that don’t understand Software development), but because those activities don’t make software any better. At best they’re a mechanism to not make things any worse. You can’t get defect free software from those processes, nor can you deliver features faster with them.
If the goal is to deliver better software, faster — or as I like to think of it, doubling your team’s productivity (word wonks: I call it ‘productivity’ when I really mean effectiveness. Marketing is hard), then you already know the truth: gated checkins, change control management, bug tracking metrics and RACI matrices will only stem the tide of disasterous changes; they won’t advance the goal of delivering better software, faster.
Cultivation, as wishy-washy as it sounds, has a role to play here. Software is created by humans, humans that don’t always understand what you’re telling them, or humans that would much rather be surfing the internet than working on a problem (mostly because there’s something about the problem they don’t yet understand), or humans that thought they understood that you said you wanted a tire swing but saw it as an opportunity to build you a treehouse.
These humans need to have a few things to produce better software, faster:
- An understanding of the requirements(!)
- The ease to make a change. Making additions and changes to a system should be easy.
- The ability to easily communicate the change and its effect on the larger system easily demonstrated
- Eliminating the bus factor when changing or adding to an existing system.
Which of those ‘control’ mechanisms provide these outcomes? None. Not because they aren’t valuable, but because these are all decisions that are made in the code itself.
That’s why Test Driven Development is central to producing better software faster, that’s why I believe that every project team should adopt it, and that’s why I care about this so much. By using TDD to cultivate practices, we can deliver better software, faster. With TDD:
- requirements are documented in the code and their tests*
- Making a change is easy; the logic is de-coupled (for non-programmers, think of it this way: You don’t have to clean out your attic every single time you want to get something out of a box)
- By running the test suite, you already know whether or not the change will cause any existing tests to fail — and these tests are fast enough that the problem is detected before code is pushed
- A system specified by tests needs two things to eliminate its bus factor: 1) readable tests, and descriptive, domain-centric names.
To bring it all together, I’ll leave you with a quote from (again) my favorite anecdotist, Josh Heyer (aka shog9) (though he wasn’t referring to TDD):
Some problems aren’t solvable so much as manageable. You don’t eliminate weeds, you just cultivate; you don’t eliminate spam, you just keep it from taking over.
Software systems are a lot like that; you cultivate good practices through an easily repeatable system of small steps, and you use the continual positive reinforcement of passing tests to drive habits. If you do that enough, you’ll have cultivated the ability to deliver better software, faster.
Is your team starting a new project in the next year? If so, now is a good time to determine whether or not learning Test Driven Development is right for your team and your situation. Send me an email and let’s chat about whether in-person training and advising will help your team’s next project become a success.