well-crafted code is expensive. good developers spending hours on fixing bad code is very, very, very, very expensive. Christoph Neuroth
Christoph wrote this some days ago on Twitter. And it sparked quite some discussion. So, a few days later, Chris tweeted:
Sigh so many reactions to that tweet that read "but we need to ship". People still don't get it. Well crafted code *will* ship faster. Today, tomorrow and in five years. Crap you ship today will kill you in the future. Christoph Neuroth
Now, you know, the thing is:
Well Crafted Code Will Ship Faster
Actually, this has been demonstrated a couple of times in the past. As a starting point, read the chapters about quality in Code Complete:
The general principle of software quality is: Improving quality reduces development cost. You don’t have to choose between quality, cost and time-they all go hand in hand. Steve McConnell, Code Complete 2
Yes, writing code well takes time. But fixing defects takes a lot of time too. Defects are rediculously expensive! And most of the customers I worked with did not even think about the true cost of their defects (in terms of lost developer productivity, lost user productivity, lost credability, ops team cost, lost business, lost market opportunities by schedule slips, budget uncertainty because of bad predictability, …). Mose companies I worked with so far simply didn’t know how much money each defect cost them!
Techniques to improve quality are not always cheap. But, overall, they are free, because:
Projects with low defect potentials and high defect removal efficiency also have the shortest schedules, lowest costs and best customer satisfaction levels. Steve McConnell, Code Complete 2
So, in software development, you cannot trade quality for speed or cost. Teams that produce higher quality also work faster and cheaper. A study about test driven development by Microsoft research also agrees: Here the teams using TDD took a little longer than teams not using TDD (estimated by Management), but:
From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM.
Again, Steve McConnell agrees too:
Writing test cases before the code takes the same amount of time as writing test cases after the code, but it shortens defect-detection-debug-correction cycles. Steve McConnell, Code Complete 2
What To No Next?
So, you need to improve quality to go faster. The “obvious” idea for most would then be: “Let’s invest in quality, then we will become faster over time”. But I think this is an extremely difficult route to go. Where do you start? Where do you stop? I think, if you start with “let’s improve quality”, there is a real danger that this effort will lead you to gold plating and no real improvements.
I think the better way to achieve this is: Just try to move faster, and fix all the problems you face. If you ship your code to customers once a year now, try to ship every three months. When this works, ship every month. And so on. Then you know what “good enough” is at every step of improvement - You know when to stop. And this is extremely valuable knowledge.
I have seen this approach working, but I cannot fully explain why (yet). I think it has some similar reasons like First do things right, then do the right things.
Get Help
Your company and your teams can probably fix most of their problems by themselves. But sometimes it’s just cheaper and more efficient to get an external expert. And sometimes you cannot solve your problems all by yourself, because of company politics. Or because you don’t even see some of the problems or solutions - you developed blind spots over the years.
Maybe, right now, you think: “Yeah, he only wants to sell his services. Why should I believe him?”. But so many teams would benefit from coaching by someone external to the team, especially when it comes to shipping faster. Just consider it, please.
Still not sure? Start with a question: Go to davidtanzer.net/contact and ask me anything - I’ll do my best to answer it, and it’s free!
Update: After a very interesting discussion on Twitter, I wrote a follow-up where I explain all concepts and terms I used in this article and provide more reasoning why I think “better is faster”: Well Crafted Code, Quality, Speed and Budget.
Never miss one of my articles: Readers of my newsletter get my articles before anyone else. Subscribe here!
You might be also interested in:
- Cheap plastic drills: Most people think construction workers should have great tools. A lot of people think paying more than 1000 Euros for an office chair is a waste of money, even for a software developer who uses it 8 hours a day. Good tools are expensive.
- Integrated Tests - The Other Side Of The Scam: Why integrated tests will not work as well as you might think.
