You’ve probably heard that almost 50% of development is re-work, right? Yep, I’ve heard it, but I really wanted to know where this number came from so we did a bit of research. According to the Standish Group, their Chaos Report year after year tells us that IT development work is really near 50% re-work.
- Most people ask the question: “WHY IS THIS ACCEPTABLE?”
- Then people use a construction analogy: Imagine having a contractor build your new $500,000 home. But then told you they had to re-do 40-50% of it over time costing you well over your budget. You may just sue them.
I simply ask: Why is re-work given such a bad rap? As a developer, re-work is just another way of building quality software incrementally. In software development, re-work is the name of the game and it’s a fact of life for a developer. We can split hairs and have different definitions of “re-work,” but in the end, I believe we should think of re-work as something not to combat, but to embrace and minimize if you can.
You’ll never get rid of re-work. But you can minimize a little of it. For example:
- You could just “understand” the real requirement and have it “documented” in a full BRD.
- You could daily review the requirement with the Product Owner and make needed changes daily.
- You could go through a detailed requirement translation exercise to functional specifications.
- You could review functional specifications, design, architectural implications to fine-grained detail.
- You could just repeat some/all these steps until zero ambiguity and requirements are fully understood and documented.
- You could just code uber fast, deploy it, then fix 50% of the bugs that come out of it in the next iteration.
Sound a bit facetious? You bet. So what’s the answer to re-work? What makes sense in an Agile shop?
Answer: Test-driven development
“In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented… By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods” – Kent Beck
- The first step is to quickly add a test, basically just enough code to fail.
- Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail.
- You then update your functional code to make it pass the new tests.
- The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed). – Agile Data
When writing this post I realized it could end up being a huge article on TDD. Instead I’ll put down the bottom line reasoning to use TDD:
A significant advantage of TDD is that it enables you to take small steps when writing software.
For more information check out the following resources:
- AgileData.org – A great resource for Test-driven development.
- JamesShore.com – Another great breakdown for TDD
- Net Tuts – A fun introduction to TDD *I like!
- Artima – Interview with Martin Fowler
- Wikipedia – The Wiki version of TDD
- Games From Within – A good case study of TDD
- DaniWeb – Introduction to TDD for developers
- Mark Levison – Article on TDD
Presentation on TDD by Jeff Langr:
If you can sit through the presentation, it’s a pretty good one.
Want a complex look at the return on investment of test-driven development?
Return on Investment of Test Driven Development