Forums

Hi everybody,

I would like to discuss one thing from the PSD material, where the use of TDD is being said to lead to a better performance of the overall development process.
I am a bit sceptical about that because I think that it *might* speed up development, but not necessarily will. I think that TDD is first and most importantly about quality. I want to have the security of being able to refactor when necessary, I want to have my different types of tests for their specific purpose, but I am not really thinking about development performance.
What is your opinion and practical experience?

Thanks and best regards,

Peter

Hi Peter, you raised a couple of very interesting points here.
I will try to address them separately.

>> I think that it *might* speed up development, but not necessarily will.
I agree. One reason for that might be that TDD is a way of working which doesn't fit every project/human.
In my experience it takes quite a long time and practice to fully grasp the idea of TDD. I started writing "tests after" 8 years ago, then 2 years later I wrote some tests first after being introduced to TDD, but still wouldn't call myself a TDD practitioner at that time. I started reading more books on OOP and TDD and practicing a lot and I think I get the idea now of driving/designing a system outside in (Some call it ATDD).
At this stage I would certainly say that TDD speeds up development.


>> I think that TDD is first and most importantly about quality.
I agree. Additionally it gives you more focus on what you are doing, defect reduction (quality again?) and faster feature time to market (cycle time).
I would even say: TDD + Scrum = effectiveness to the max



>> I want to have the security of being able to refactor when necessary,
Definetely a benefit of TDD.


>> I want to have my different types of tests for their specific purpose,
>> but I am not really thinking about development performance.
Isn't Improving Quality (which TDD gives you) the only way to speed up your development?

BTW: I think that is the idea behind the Software Craftmanship movement:
"Only Quality lets you go faster"
http://manifesto.softwarecraftsmanship.org/

Hi Peter,

thanks for your valuable input and the interesting points that you made.

> I agree. One reason for that might be that TDD is a way of working which doesn't fit every project/human.
In my experience it takes quite a long time and practice to fully grasp the idea of TDD.

That is my impression also. In every team that I supported (using Scrum or not) that wanted to do come more to a TDD style of development it took quite some time to get the approach into the developer's bones.

> I would even say: TDD + Scrum = effectiveness to the max

This is a very nice way of putting it - especially since it emphasizes that you can do either one without the other, but combined you gain the most of it.

> Isn't Improving Quality (which TDD gives you) the only way to speed up your development?

> BTW: I think that is the idea behind the Software Craftmanship movement:
"Only Quality lets you go faster"
http://manifesto.softwarecraftsmanship.org/

Thanks a lot for the last statements. When watched from that angle, the hypothesis that TDD speeds up development is very straightforward.

To summarize it for me: first you have to learn how it works (learn to walk), then you become better and better (run faster and faster, even when you fall sometimes) until you really speed up and benefit from the exercise.

Any other opinions are still very welcome and appreciated. :)

Best regards,

Peter

The thing to consider here is the time taken to get a feature to an acceptable state (in scrum terms a part of a potentially shippable product).

If we take the myopic view that the development time is simply the raw time the coder spends banging keys until the feature is first visible then of course TDD doesnt on average help, but this is not consistent with a meaningful Definition of Done.

TDD helps us to ensure the quality and reduces the "rework", "refactoring" or "bugfixing" effort in actually reaching a usable product. In this sense in does speed up the development time. It also makes it much easier to be confident that the DoD is reached.

Hi James,

thanks for your thoughts on this topic. I agree with you if we are talking about a good team that really understands TDD and is experienced with it. But I was a bit sceptical about the generality of the statement:
TDD -> faster development
This causality is a bit dangerous in my opinion since it implies some kind of silver bullet (and we all know that Scrum is *not* a silver bullet, and I think the same goes for TDD).
Otherwise I agree with the statement, since I think that as an experienced TDD developer team, you will improve your quality and therefore become faster in development.

Best regards,

Peter

I'd just like to add one more angle to this topic.

If you consider "The overall development process" to include fixing bugs, then TDD really speeds up the process, because:
1. The released code will automatically contain fewer bugs, since (pretty much) all production code is covered by tests.
2. Locating the source of a bug in a codebase with a substantial test coverage is MUCH easier than without tests.

Just my 5 cents :-)

Kindest regards,

Mikkel