A friend of mine pointed me towards one of last Kent Beck’s mini-essays: Just Ship, Baby. While reading it I felt more and more surprised: I was hoping to find a controversial but sophisticated provocation directed towards those who hide behind the process and fail to deliver because of it. That can be quite common among those teams that are approaching agile methods for the first time and fail to understand and embrace the pragmatic essence of methods like XP. It’s a kind of error that can happen frequently for teams coming from a waterfallish culture and it’s always done in good faith. The rules are tools and they change over time, based on the circumstances.
Despite his good intentions, though, I think that Beck has failed to ship the right message, so to speak: the examples are quite misleading because when I’m exploring a technology that I don’t know well enough, the right way to go is spiking and prototyping until I get the answer that I’m looking for. Under these circumstances, only at a later stage it makes sense to apply TDD, typically when you have played enough with the technicalities of the specific API. Certainly, this shouldn’t happen anytime sooner than when you feel safe filling the gaps related to the expectations in your tests. So, I’d say that Beck’s problem in this case has been VIOLATING what I consider one of the implicit rules of TDD: don’t write your tests until you have enough understanding of the modelling mechanisms of the API / framework / system you are dealing with. TDD can be used to explore those mechanisms, but that’s a completely different story.
There’s actually even more there: if I’m just interested in evaluating the feasibility of something, then a throwaway prototype seems a better idea. When you have confirmed the feasibility, and only after that, then you make tabula rasa and develop your system applying TDD consistently. No shortcuts, but different approaches depending on your intent. I don’t think there’s anything new in this.
Going back to Beck’s essay original intent (as I understand it), I think that the target has been missed: the issue whether you follow the rules or you deliver the system has not been addressed. First of all, it’s a faulty dilemma if you put it like that. If there’s one thing that agile methods have taught me it’s that delivering a system and/or completing a project are the result of trade-offs, continuous negotiation, constant planning throughout the entire project life, reassessing current status and goals based on feedback. But let’s put all those considerations aside for a while and let’s consider a situation where a short-term deliverable can be achieved if some of the practices are relaxed. In this situation, the team incurs typically into some significant technical debt or, even worse, the external quality of the system is severely affected. What should you do? Well, it depends and as usual it’s a judgement call.
There are situations in which it makes perfect sense and it buys you time to clean the system immediately afterwards. I haven’t seen this happening many times, especially because it requires a perfectly healthy, open and honest environment, but I accept the idea that it can happen. On this subject, for example, there was a blog post by James Shore a couple of years ago which triggered an interesting and lengthy discussion in the XP mailing list.
There are other circumstances where the system can already be so compromised that no more design debt can be tolerated or the lack of correctness of the software can cause financial loss (or worse). My experience is that this is much more likely to happen and when it does its consequences can be devastating. Saying “Just ship, baby” can have catastrophic effects and it’s ultimately irresponsible.
It’s so annoying having to test all that code and solve those bugs. Real programmers write correct code and eventually solve bugs instead of sleeping. That’s what we are paid for, aren’t we? I fear that Beck’s post can ultimately feed the despicable culture of Macho Programming.
Delivering software is not like winning a football game: it has consequences that need to be taken into account. In sports, when a game is over, it’s over: unless you have broken the law, got some dope or other things that have nothing to deal with sport itself, every game is self-contained.
Software development though it’s different. More than often the consequences of your actions come back at you, sometimes in very unpleasant and everlasting ways.