So, ya need that techie-friendly quick-pick-list to explain to someone why your project simply cannot live another second without TDD? I know I did, so I created one. And I'd like to share it with you faithful readers.
Confidence & Productivity … Today
- Immediate feedback, ie. "cookies": Green bars that give me full confidence in what I’m coding, or in other words, meeting requirements with decreased bugs
- A more efficient design:
- Clear “expectations” (tests) drive my mind quickly and smoothly to solutions (algorithms)
- Good public interfaces – my tests make me “eat my own dog food”
- Simplicity – I’ve coded only what was needed to pass the tests
- A more effective design: in order to write software that is effectively tested in this manner, I’m naturally encouraged to ultimately write more cohesive and less coupled code
- Test “protection”: “my tests” give me freedom to refactor mercilessly to create a more expressive, readable code-base while I’m coding
- And then even more Test “protection”: “all the tests” allow the build to silently ensure that today’s collective changes across the group haven’t broken any windows
Confidence & Productivity … Tomorrow
- Fact: addressing yesterday's bugs exponentially decreases today's productivity...unless:
- yesterday 's TDD decreases (if not nearly altogether removes) yesterday's bugs
- Fact: most bugs occur upon changing an existing code-base...unless:
- Today’s [automated] tests become your safety net tomorrow
- Growing test suite allows build to be the perpetual “silent police”
- Fact: easy to understand my design; hard to understand your design...unless:
- Today’s [expectation-based] tests become your documentation tomorrow
- My expressive code is easy for you to understand tomorrow
- Fact: “code rot” (poorly factored code) slows development over time...but:
- My tests force me to keep my design well-factored – forever!
- Fact: “paper documentation” gets outdated (and lies!) over time...in contrast to:
- Automated Storytests: up-to-date, runnable “what it does” documentation (analysis)
- Automated Microtests: up-to-date, runnable “how it does it” documentation (design)
Of course, I'm not perfect, and feedback is king. So, please, pretty please with sugar on top, let me know how you think this list can be improved!
Posts
Excellent summary!
ReplyDeleteOne thing I would like to add however is that since you are using TDD you will reduce the number of defects found in the code drastically. Interesting to note is that the defects that remain (in my experience) are mostly related to high level business logic and requirement interpretations. As a consequence it makes the job of the testers so much easier and rewarding since the code received is more or less free from 'normal' developers mistakes (null pointer exceptions, wrongs casts etc.) and as a tester you can concentrate on the requirements and business logic, things that are hard to test earlier since you normally only test your module and not the whole system. Or in other words, the defects that you will find are 'real' defects and not just programming typos. This will of course make the testing cycle more efficient, so it's a win-win for everyone.
Cheers!
/Claes
Hi Mike,
ReplyDeleteI stumbled across this page from a post you made on http://www.infoq.com/news/2009/03/TDD-Improves-Quality
While your article is an excellent summary (I'm a techie by training) unfortunately I don't think it's an elevator pitch. I'm starting a business and I'm coming across the non-techie higher-ups in organisations that ask the question: "what does this mean in real money terms?" or, in the case of one customer: "how does this help me sell more cheese?"
If we talk about "coupling" or "cohesion" to these people, who may have no training/understanding of software development practice, we need to use simple, universally understandable statements that can be understood by someone looking for the cash payoff.
These people seem to get turned off by technical words and aroused by, "Hey, I'll save you 10-15% of your software development costs."
Just a thought, I hope it helps you convince more people to improve their development practices.
Best Regards,
Ciarán Greene
Ciarán, I think you right. Probably not as stated the "elevator pitch" you're gonna be using with the business folks.
ReplyDeleteMaybe I can follow this up with an actual pitch for your execs.
Maybe then this could fill as the "happy hour pitch" when you've got the techie in sights? :-)
Anyway, thanks for the observation!
MB
Updated, no longer being advertised as the "elevator pitch" (that'll be on its way soon enough)! :-)
ReplyDeleteMB