Agile Development and RE-WORK – Look at Test-Driven Development (TDD)

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.

  1. Most people ask the question: “WHY IS THIS ACCEPTABLE?”
  2. 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

  1. The first step is to quickly add a test, basically just enough code to fail.
  2. 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.
  3. You then update your functional code to make it pass the new tests.
  4. 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.

Not convinced?

For more information check out the following resources:

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

5 Replies to “Agile Development and RE-WORK – Look at Test-Driven Development (TDD)”

  1. Hi, I just tweeted about #TDD and then saw your article, gives a great introduction!

    As an answer to your question: I am not convinced. 🙂 Yes, I really like for example unit/integration testing, but consider ‘test driven development’ aiming at 100% test coverage of source code not working as a principle. The Wikipedia section gives a good overview on disadvantages of TDD (see sections Vulnerabilities/Visibility).

    Personally I was undecided on what to think about TDD for some years, used it at work, talked to different developers and just recently changed my opinion when reflecting about W. E. Deming’s key principles (Total Quality Management), e.g. the following one about the dependency on mass inspection

    Maybe TDD should be interpreted as ‘test influenced development’, which would be fine if we also draw the consequence… that testing is only one of many tools to avoid waste and increase quality.

    Many greetings from an agilist in Sweden!

    1. Thanks a lot for your feedback! I’ve been getting different levels of feedback on it. TDD is a valuable topic to have a conversation about. It depends on the situation, most certainly.

Leave a Reply