Premature optimisation, testing obsession, architecture astronauts, pattern abuse (or “Pattern Wankery” to use @dhh’s term), methodology slavery, and best practice fascism: all are the result of a lack of constructive scepticism.
Of not asking enough questions.
Why am I doing this?
Why is this better?
Why should I care?
Does it really matter?
One of the fads that has cropped up in the last few years has been Testing Obsession. The obsessed spend massive portions of their development time ensuring ‘perfect’ test coverage at every level of their application, from model code to integration and every point in-between, using every tool available. They brag about their code coverage and their code/test ratios. However they are frequently doing it without understanding why, and what the costs and benefits are.
Don’t get me wrong, I’m a big fan of testing, good practice, clean design, and well architected code. Testing is a Good Thing™. At Storm we stick roughly to the principles of Test Driven Development and I’ve written in the past about why I like TDD. But there are limits to how useful testing can ever be.
I know all about testing and its limits. In a previous life I worked in the safety critical embedded systems industry. The stuff they work on can be divided into three types:
- Things that should never go bang – planes, trains and automobiles
- Things that should go bang, but in a controlled fashion – missiles, bombs, rockets, jet-engines
- Things that stop those things from going bang – air traffic control, auto-pilots, engine controllers, weapons management systems
A huge amount of effort goes into making such systems incredibly reliable and, just as importantly, demonstrating them to be reliable (the FAA won’t just take your word for it). It’s common for actual coding to take just 15 per cent of a project, dwarfed by requirements, specification/design, and verification/validation (testing, code review, static code analysis and formal proof). Test and analysis teams are frequently bigger than development teams.
But effort is always proportionate to the level of reliability required.
We were skeptical, we analysed what we did and its outcomes. We enforced coding standards and processes, but they were guidance, not dogma. We regarded self-proclaimed high-priests of process and their magic bullets with a wary eye. We wanted proof that something was worth it, not just a warm fuzzy feeling and a sense that what they were saying was good because it sounded ‘right’.
We were even skeptical about the problem itself. Was it really as safety critical as we thought? Could we change the problem to make it simpler and easier to solve? Did only parts of it need to be highly-reliable?
We could have thrown the kitchen sink at every part of every project but we’d have gone bankrupt in the process, wasting our time – and more importantly our client’s money – in the pursuit of some mythical perfect software.
Of course quality is important, of course reliability is desirable, but there is a law of diminishing returns. In a world without deadlines or limits we’d all be building perfect software, bug-free and beautiful. But we don’t live in that world.
We can always do more testing, refactoring and optimisation, spend more time on process, or write more documentation. But no amount of testing will make for perfect code. No amount of refactoring will give you the perfect architecture (whatever that might be). There will always be optimisations you can make. And no process, no set of design principles, no patterns, no guidelines or standards or best-practices, no matter how good, no matter how rigorously applied, will make bad programmers create great software on time and to budget.
So relax. Unless you are a rocket scientist I’m betting that whatever you are working on right now probably won’t kill anyone if it goes a bit wrong. That doesn’t mean you shouldn’t make it good, but it will never be perfect. So get used to it.
A smart person once said: “Perfect is the enemy of the good”.
I’d go further.
Perfect is the enemy of the goddamn f*cking amazing.
While you are going bankrupt doing your third ground-up rewrite because your architecture wasn’t ‘perfect’, or sending everyone to yet another Scrum workshop*, the guys across the street are working on something that might just change the world.
So if you find yourself obsessing over your architecture, or spending four times longer writing your tests than the code it’s testing, ask yourself why. And the next time someone tells you their way is the One True Way to software nirvana, demand some proof, and if they haven’t produced something amazing as a result of it then you can probably move on and find someone who has.
If they want to be your messiah, demand some goddamn miracles.
* I have nothing against Scrum, but it does seem to inspire some of the most tiresomely dogmatic obsessives, many of whom don’t actually have much to show for it.
