4

The importance of TDD needs to be propagated but there's always a gap in the project timeline and time needed for developing a TDD project. Customers usually do not understand the importance of code maintenance or TDD and want the project to be finished as soon as possible.

The result would be a Test After Development which would be very basic minimal tests to please the coverage tools and let the project analyzers have a great Graph.

Do projects developed using TDD take longer, or is that just an unfounded fear?

Improve this question
8
  • 10
    TDD is an investment in maintenance cost, not initial development.
    – user1249
    Commented Dec 14, 2011 at 12:43
  • 1
    @ThorbjørnRavnAndersen This is a great comment that should be an answer IMO.
    – maple_shaft ♦
    Commented Dec 14, 2011 at 12:53
  • 1
    TDD is a process for writing code. I don't see it as an investment. It's just what I do to get code written.
    – xpmatteo
    Commented Dec 14, 2011 at 13:00
  • You stuck a question at the end of your assertion. Which do you want to know--the importance of emphasizing TDD to customers (personally: I wouldn't), or whether TDD lengthens development time (which has been asked elsewhere on this site)?
    – Alex Feinman
    Commented Dec 14, 2011 at 13:09
  • 1
    It is very difficult to answer a question which starts with an assertion which is, in my experience, wholly incorrect. If TDD isn't bring in projects in less time than non TDD projects, then perhaps you should try to find yourselves a new silver bullet.
    – Mark Booth
    Commented Dec 14, 2011 at 15:23

8 Answers 8

Reset to default
18

As a project leader and if possible in any way, I would not even talk about TDD with the customer. The customer cares that the project is finished at the deadline you agreed on before. They probably don't care whether you write your project using AWT or Swing, sometimes not even whether you use Java or .NET. Why should they care about TDD or no-TDD?

Improve this answer
11
  • 3
    @AravindA - He says that you don't even mention TDD to the client.
    – Oded
    Commented Dec 14, 2011 at 12:13
  • 3
    Yes, as Oded said, it's your team's business how you do your programming, not the customer's. If the customer wants to take control over that, he has to hire his own team, but they hire you because they can't or don't want to and because they want someone who knows how to program properly. That's why TDD or no TDD is your choice, not the customer's.
    – Raku
    Commented Dec 14, 2011 at 12:40
  • 5
    they would bombard you with requirement changes within half the timeline you usually have. This is the real reason that TDD and Agile seems like it is not working for you. Agile IS NOT an excuse for stakeholders to continually change the requirements on a fixed deadline project. The word you are looking for there is exploitation. Time taken in unit tests should be incorporated in overall development time and requirement changes should result in an adjusted deadline or pushing some features out to a future release.
    – maple_shaft ♦
    Commented Dec 14, 2011 at 12:52
  • 12
    Dealing with requirement change has a silver bullet solution. Repeat after me : "Ok, we can definetely change [insert feature here], but it will delay the deadline by [insert number here] days. What is worth the most for you, the deadline or the feature change?". You need to responsabilize your client, that will make in think if he really needs what he asks.
    – Clement Herreman
    Commented Dec 14, 2011 at 14:43
  • 5
    @AravindA - In my experience, if your TDD projects are taking longer than the same projects without doing TDD then you are doing it wrong. Similarly, if your customers are bombarding you with requirement changes and you don't have an agreement for how to deal with that then your project manager is doing it wrong.
    – Mark Booth
    Commented Dec 14, 2011 at 15:19
7

I agree with Raku that you better not talk about TDD with your customer. Maybe tell them about TDD after you completed the project and they ask you how you did it so well :-)

I don't think that TDD projects always take more time. They certainly will take more time if the team has not learned to do TDD well. I would suggest that first, you take the time to learn TDD on your own, until you can do it well and without effort; then you share the technique with your team only when you can do it well yourself.

Improve this answer
4

While Raku's answer is correct - these decisions/implement details don't concern your clients/customers, you don't seem to appreciate the business factors facing your customers.

It's likely they understand the importance of maintenance, but other factors take priority.

Another answer on another question highlighted the time to market factor for mobile games. It is better for business to have software that to sell today than tomorrow, especially if competition is developing something similar.

It is better for business to have usable software in the wild than something sitting in the lab being re-tested and re-tested.

Your customers will decide whether the investment is worth it and if their product is successful they can reinvest in maintainability, but based on those decisions you have to toe the line to get it done for the cost/budget quoted (if you use TDD, then time for your development is factored in estimates for these quotes). If you've got time to do TDD within that quote and your estimates, you should use TDD, but if you don't have time then you can't afford to do it.

Improve this answer
5
  • 2
    AHAH, don't dream. When your customer will see bugs and longer and longer time taken to add feature, they will blame you, not themselves, for not having made enough test. Client always believe that their soft will be like a Google/Apple/Microsoft app, bugless, and doesn't realize the importance and the cost of testing, to attain such quality.
    – Clement Herreman
    Commented Dec 14, 2011 at 14:46
  • Very good point Clement, and it's possible to follow plans on quality decisions AND highlight risks before they make that decision. Ultimately though, their decision based on the time/quality/cost triangle is their responsibility.
    – StuperUser
    Commented Dec 14, 2011 at 14:49
  • right, you might want to hightlight the risks, but the client will still held you responsible, at least in their head, and probably in their recommandations to other. I stick with aku's answer, you client tell you what they want, you decide how you realize it.
    – Clement Herreman
    Commented Dec 14, 2011 at 16:48
  • Indeed, hence "if you use TDD, then time for your development is factored in estimates for these quotes". As Raku says, they don't have a say in technical decisions. I was highlighting the fact that customers priorities often aren't software related, they're business related. I agree with you whole-heartedly about responsabilizing your clients.
    – StuperUser
    Commented Dec 14, 2011 at 16:57
  • 1
    Ok. The difference is that I don't give client the choice of whether I'll do TDD or not. I'll do it, and it will be included in the quotes. Also I firmly believe that TDD doesn't ease only the maintainabilty, but also speed up developpement, if the project reach some size/age. It helps keeping complexity under control and detecting code smells/wrong design.
    – Clement Herreman
    Commented Dec 14, 2011 at 17:00
3

"Very basic minimal tests" sounds like you aren't concerned about product quality. This has nothing to do with TDD versus non-TDD, it has to do with the quality standards of your team.

TDD isn't a magic bullet, but I think it's safe to say that if you think you can cut the amount of testing you do so that you can deliver earlier, the only thing that does for your customer is to potentially give them a lower quality product. Only you can say whether that is an acceptable risk. Delivering a clone of tetris for an android tablet? It's acceptable. Writing software for medical equipment, not so much.

So, before you discuss TDD or non-TDD you need to decide whether quality is something you care about or not. Once you decide to commit to delivering a quality product rather than one that has "minimal tests", then you can start to discuss whether TDD is the appropriate way to do your testing. TDD isn't about how much testing you do, it's about when you do it. From the sound of your question you're more concerned about how much testing to do.

Improve this answer
0

I think customers like to know that you follow solid practices. Sometimes they understand TDD. You may be working on a side project outsourced by an IT manager and prefer consultants who have the same standards.

I don't think you can use this as a reason to bill for more hours compared to your commpetition. The client wants results. The risks of not following sound practices are absorbed by you and not the client. Otherwise, they'll go where someone else can convince them they'll deliver. Imagine a carpenter wanting to charge you double because they "measure twice and cut once."

Improve this answer
0

The result would be a Test After Development which would be very basic minimal tests to please the coverage tools and let the project analyzers have a great Graph .

That's not the point of testing. Testing in itself adds no value. If done properly, various types of testing can improve correctness, flexibility and usability of a software. You are selling a product, not the process.

Unless a project is so extremely small, that it can be properly implemented without iterations, you can make good use of the flexibility that robust code adds (TDD being one of the more popular and easy ways to achieve robustness). There is a little overhead in the first iteration of a functionality, but you can respond to changes quickly and the overhead is amortized long before the last iteration. So on a grander scale of things, you're probably going to be faster.

Improve this answer
0

TDD is of course a better methodology for making the project timeline shorter. It also helps the developer to move towards meeting the customer's requirements for the product functionality.

Improve this answer
2
  • 1
    Can you expand on that please? How does TDD do that?
    – Adam Lear ♦
    Commented Jan 5, 2012 at 6:31
  • If tests are written and named properly they can serve as a documentation of the user's requirements as well. I believe Dan North has introduced this concept in his article on behavior driven development (BDD). Find it here: dannorth.net/introducing-bdd
    – Raku
    Commented Jan 12, 2012 at 15:19
0

If you development process focuses on producing carefully crafted code (including design, unit testing, documentation, version control, traceability...), TDD should not cost much more time.

Moreover, TDD allows huge time gains in maintenance, especialy when customer asks for a new feature that needs a big refactoring.

Quoting Thorbjørn Ravn Andersen:

TDD is an investment in maintenance cost, not initial development.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.