One of the important event in Agile this year seems to be an argument around Test Driven Development (TDD). More precisely, high profile personalities in our industry debated against the statement "TDD is dead". Initially launched by David Heinemeier Hansson at the RailsConf keynote, it created quite a buzz in the Agile community. Key Agile figures addressed the statement through Google Hangouts and posts on their blogs. On this quickly generated Google Trends graph, you can see how the words "tdd is dead" spiked during the summer.
I'd like to add my 2 cents to this debate: Really! That much fuss for just a Agile dev practice.
I recall from one of Mary and Tom Poppendieck book how the goal of IT is to solve a problem. And most of the time, it is a business problem we are trying to solve.
In my opinion, Agile hasn't got us better at doing this. We deliever features faster and of better quality but nothing is saying that we are actually solving the business problems at hand. Surveys by CHAOS, Standish Group or Dr. Dobbs don't even agree on a definition of what a successful project is. It is hard to state that Agile solves the business problem better than other methods. In the epilogue of their book "The Lean Mindset", the Poppendieck summarized their view of Agile methods. They stated how "agile methods often fail to deliver significantly improved business results".
I believe we should work harder at finding ways to work with our customers to identify solutions to their problems. We should engage with them to build software which is of value to them. This should be our most important concern. Once this is discovered, identified and proven, use TDD or whatever suites your needs to build this feature.
I recall a few years ago a popular commentary TV show where the host interviewed the minister of Health in my home province. The host asked tought questions about the latest reforms in healthcare. The politician replied with well made answered throughout the interview. He was well prepared. He had his pre-fabricated answers with him. The host then asked: "What about the patient in all of this? I haven't heard anything about the patient in your answers."
Doctors work to save the lives of patients. They do not argue all day about which kind of scalpel to use. As professionnals, we should do the same. We should work on solving the business problems of our customers and then pick the scalpel that is the most fitting to our situation.
That much fuss about TDD
What did you think about this post?
Share with your network
Comments (9)
I bet good doctors do indeed argue about their scalpels. In fact, I am sure of it!
As long as they argue about it before my major operation and without delaying my operation then I'm fine with that but once we are in the theatre get on with the job at hand.
I agree with you Louis, we definitely need to focus on the customers needs and use the most suitable method to meet that need, whatever it is.
Thanks for the feedback Shaun. I wasn't sure how this post was going to go. When I was learning computer programming in the 90s, I was myself caught in languages wars. Is C++ better than Java or this new language coming out at the time C#. It took me a loooooooong time to finally focus on customers.
As a patient I'd prefer that the doctor use a scalpel and not a machete, that's a proper analogy I think.
We are in the same boat. Focus on business. Software Development is just a way to achieve business goals.
Hi Louis-Philippe
I think all these discussions about usage of TDD is because it is much easier for SW engineers to argue about engineering practices than how the best to satisfy customer need or as you put it “to build software which is of value to them”. My view is, if you are building SW which satisfies customer and has right quality, what engineering practices you are using is irrelevant. I want to believe that most companies try different engineering practices and choose those ones which suit them best or solve most of their problems
Regards
Zoran
Again I believe the buzz comes from people talking about different levels of agile. TDD is a practice that is about the quality of the build product. It has - of course - nothing to do with solving customer problems.
Furthermore, I think the buzz is, because TDD is used by some in the way of "Tester defines Tests first, than there is development" while the classic XP development approach of "writing unit tests first" is completely different.
So I claim: Instead of calling TDD dead, those people should learn what TDD is ("Red, green, make it clean" anyone?)
you are right! Many successful startups hardly follow any method. They just code and implement to solve a perceived customer demand.
As a corollary a lot of the Scrum Masters, Coaches and Project Managers would be out of a job today if they were asked to do any real work
Some say TDD is dead, long live BDD!