FlexDev In Action
In a recent article, James Shore describes the dynamics in the CardMeeting project.
“All of these things would have been good things to fix. In particular, implementing tests would actually have made us faster, and it would have only taken a week or two at most to figure out how to use TDD in our UI- and network-intensive environment. But–here’s the rub–even a week or two delay would have meant no Agile 2006 demo […]
The thing about technical debt is that you aren’t just deferring costs. You pay interest on those costs… even when you take on technical debt for as little time as a month. I can’t say how much time the technical debt is costing us, but I would guess that it’s anywhere from two to four weeks of extra work.”
And that’s FlexDev in all its glory. What James Shore and his colleague did in this project is a clear deviation from the “classic TDD”. But they did so for a good reason. Implementing TDD rigorously in the CardMeeting project would have had undesired consequences (missing the deadline for the demo). So, they decided to be flexible — to adapt their development process to their current reality.
Does that mean you can skip any part of your development process just because you don’t have time? Well, you can, but only if you are doing so consciously, and if you’re willing to pay the price. James Shore’s didn’t leave his project without unit tests for long, and the development team was willing to pay the price inflicted by not writing tests first.
I’ve said it once and I’ll say it again: reality is too complex to be addressed by a single methodology, a single standard, or a closed set of best practices. You have to constantly analyze your goals and your constraints in order to come up with the optimal solution for each given context.
That’s the essence of true professionalism. It is this kind of professional integrity which created the apparent irony of presenting a product developed without a single unit test in an Agile conference. What could be more flexible than that?
September 20th, 2006 at 10:04 pm
The idea of taking short-term debt as a measured risk is common in finance — here it is in software development. The example, though, is producing a demo. Not a very broad example — many development organizations make different rules for demos and experiments than they do for production development.
Shore’s example would look a bit better if he had told us about it after they had recovered and paid back all the debt — cleaned up all the bugs and restored a full unit test suite, rather than just leaving us at “taken … a month so far and … quite a bit left to do.”
In addition, Shore has the luxury of running his organization, so he makes the decision on when to pay back the technical debt. Many readers work in organizations where their environment makes them take the debt but never lets them pay it back. E.g. write something as a demo but then deliver and maintain it in production without slowing down to complete the unit tests they left behind.
Maybe a future post should be about overdraft.
September 20th, 2006 at 10:15 pm
That’s a good comment, Tom.
The financial metaphor actually demonstrates very vividly why not paying the debt eventually is a bad idea. Hopefully, organization leaders will realize that… unless, of course, they manage their financial affairs in the same spirit.
Lidor