When is Ok to Break the Rules

Posted by Mark Levison on Sep 18, 2008 09:11 AM

Community

Agile

Topics

Unit Testing ,

Delivering Quality ,

Agile Techniques

Tags

XP ,

TDD ,

Quality

In “Just Ship Baby” Kent Beck, author of the JUnit Framework, reminds us that the point of all the Agile processes and practices is to produce shipping software. If they’re getting in the way of shipping software – then perhaps you need to break the rules.

Quoting, Al Davis, general manager of the Oakland Raiders, who once said “Just win, baby”, Kent describes the troubles he had trying to write an Eclipse Plug-in Test First to experiment with an idea he had.

For six or eight hours spread over the next few weeks I struggled to get the first test written and running. Writing tests for Eclipse plug-ins is not trivial, so it’s not surprising I had some trouble. I just kept bashing at the problems, trying to get that first test to run cleanly.

So after eight hours work, he still doesn’t have a useful test nor has he succeeded in testing the original idea. A few days later he tried another experiment in Eclipse this time without any tests and it was uncomfortable he was able to demonstrate after three hours work that the experiment wasn’t such a great idea.

Piergiuliano Bossi, feels that Kent shipped the wrong message. He believes that Kent was really just doing an investigative spike exploring the eclipse plugin structure and trying to understand how to write tests in that environment. Piergiuliano thinks it’s normal to explore the api without TDD, waiting until you’ve enough of an understanding of the api to come back and rewrite the code.  He wonders when there might be a case for relaxing the rules and what the consequences might be:

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.

…

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.

He fears that Kent’s post will just “feed the despicable culture of Macho Programming.”

Five years ago, Uncle Bob, wrote on the same subject:

Blindly following rules is a fools errand. We have enough grey matter to discern when the rules are helpful and when they are not. We have the responsibility to continuously measure whether the rules are helpful, or whether they are not.

But he tempered that observation with:

Our core of professional pride is the cure.  That something that is both cold and hard, yet hot and blazing.  It won't set aside a rule out of fear. It sets aside a rule when the rule will cause you to ship shit.

So it would in the minds of Piergiuliano and Bob the thing to keep in mind is that quality is what really matters.

1. Back to top

   Perhaps the disheartening thing out of Kent's article....

   Sep 18, 2008 9:21 AM by Mark Levison

   ...is not what he said. But that eclipse can make so difficult for someone of Kent's skills to work with Plug-ins. Sadly this mirrors my own experience - alot of time can be wasted trying to figure out to structure your test plugins so that they work with well with the Java classloader, ...
   
   
   Consider that if Kent can't do it then most people new to Unit Testing/TDD in Eclipse will give up before they even get started.
   
   
   
   Very, very sad.

   Reply

2. Back to top

   No Silver Bullet...

   Sep 19, 2008 3:43 PM by Paul Beckford

   Sounds like sound common sense to me. Kent found an exception to the rule and done the right thing. I agree with the previous comment, this episode probably says more about Eclipse plug-ins and the Java classloader then it does TDD.
   
   
   
   BTW. Kent Becks XP book was the first "methodology" book I came across that took the time to suggest scenarios where the methodology may not be the best fit. I think this article is just an extension of this pragmatic and honest approach. You've got to respect the guys honesty.

   Reply

3. Back to top

   Some Environments just don't enable TDD

   Sep 23, 2008 7:05 PM by Andy Dent

   I remember when I went from being a long-term user of regression tests and delivery tests (early VMS influence) to getting TDD religion.
   
   
   BUT
   
   
   I was working on Quicktime Plugins at the time - a very deeply embedded environment with soft-realtime constraints, an environment which changed behaviour depending on how long your code took and a very broad API. I challenged one of the TDD gurus on a mailing list for how to do TDD in this situation and his answer, eventually, was "don't".
   
   
   
   It is unproductive to push TDD religiously into certain environments and sometimes even automated regression testing isn't a reasonable goal.
   
   
   
   With heavily embedded code, sometimes, the cost of writing the mock framework to invoke it with reasonable values is just too high. There's also an issue of Architect's Rights - just why should the Eclipse creators have warped the structure of the product to make TDD development of plugins easy? What tradeoffs would that have involved and just how big is the group who would benefit?

   Reply

• Older >