I just read Itamar Syn-Hershko’s response to Uncle Bob’s Giving Up on TDD? (itself a response to Ian Sommerville’s blog). In his article Itamar proposes an approach to software development that he calls “Spaghetti Driven Development”. To be honest the opening remarks in his post were so maddening that I had to read the rest of the article just to be sure he wasn’t trolling (I’m fairly convinced he wasn’t but if he was, well done, you got me).
I’m not going to defend TDD itself here, as this has been done admirably by many before (eg. http://www.davefarley.net/?p=203) . No, my beef here is the seemingly never ending accusations of “Preaching” TDD from people who don’t know how to use the technique or even bother to try to learn it. I think quite the opposite is in fact the case and it is often they not the TDDist’s who are the preachers.
On to the post that made me write this rant in the first place…
In his article Itamar states upfront :- “I never really did TDD and probably never will.” – Well, at least we know his position on the topic is one held from a self-declared position of ignorance in it.
“I never really did TDD and probably never will.” – Itamar Syn-Hershko
He then goes on to explain an alternative approach to software development giving it the name “Spaghetti Driven Development”. His approach as far as I can tell is in essence;
- Write terrible spaghetti code
- Refactor into something more understandable
- Then and only then write tests
What the author is perhaps unaware of is that many of us, who are proponents for TDD, have been on a journey through software development and on that journey we have used approaches like this (among others) for many years. But, unlike the author, we found ourselves dissatisfied with the results. Ironically then, it is through our extensive experience of this type of approach, rather than ignorance of it, and through a continued desire for lifelong learning that we have chosen to look at alternatives such as TDD.
From a personal viewpoint I would summarise my ongoing journey in my understanding of software development as follows. Its worth saying that in all these approaches I have been privileged to have worked with many excellent developers and we delivered commercially successful products which I believe were to some of the highest standards achievable with the tools and techniques of the time.
Write some spaghetti code and refactor it until it was tidy enough I could understand it. No automated tests but who did back then? This was when I was still at school and just beginning to learn how to code.
First professional job as an Analyst/Programmer. Small up front design, code and refactor manual testing – some of us were still arguing if “goto” was a good thing back then and COBOL wasn’t just legacy.
Big upfront design, starting to use some automated testing but only after development and often by a separate test team (as an aside; it seems this is about the time that somehow we moved away from the analyst/programmer who did everything from requirements capture, through deployment and support to user training and into more segregated roles of DBA/SysAdmin/BA – I’m glad to see the DevOps movement finally starting to bring this back again. The use of patterns and OO started around here for me, along with a brief foray into Functional Programming in ML.
Small upfront design, code and refactor, lots of automated testing after the code was written – this is the period where what I practised was closest to the approach Itamar seems to be championing.
Present day almost exclusively ATDD/BDD and TDD in line with what’s generally recommended for Continuous Delivery.
Even today I find that too often we have to refactor spaghetti code, almost invariably when encountering a code base which wasn’t test driven. Fortunately for those of us who have seriously undertaken to learn and apply TDD, our understanding of what good and testable looks like has been massively advanced by having done so, but it still hurts.
“Personally, right now, I would not consider hiring anyone into any senior development role unless they had considerable experience with TDD.” – @thinkfoo
The very nature of software development makes comparative studies difficult but we are increasingly seeing actual evidence that TDD and other Lean/Agile approaches to development such as continuous delivery are demonstrably better than the current known alternatives (see Puppet Labs 2015 State of Devops Report for example).
Personally, right now, I would not consider hiring anyone into any senior development role unless they had considerable experience with TDD. Whatever your position on it, TDD has been around long enough and is widely enough practised that, any senior developer, should, in my opinion, have taken the time to learn and properly understand the technique, even if they then choose not to apply it on a daily basis.
Now I don’t necessarily believe TDD is the end of the journey and perhaps it will be superseded. Indeed if someone has extensively practised TDD and subsequently has ideas and arguments for a better alternative; Fantastic, lets hear about it! If what you have is genuinely new and valuable, all us “TDD Preachers” would, I am certain, be very interested to listen and learn. But to convince us, you first will need to have used TDD full-time, for a prolonged period, with other skilled practitioners. But unless you have that authority and vision, please don’t risk peddling your own snake oil, I believe it is only serving to confuse the issue.