Skip to main content

PSD: is TDD really speeding up the development process?

Last post 08:27 am December 13, 2012 by Mikkel Toudal Kristiansen
5 replies
08:54 am November 30, 2012

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


05:32 am December 2, 2012

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/


03:50 pm December 4, 2012

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


10:55 am December 5, 2012

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.


01:32 am December 10, 2012

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


08:27 am December 13, 2012

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.