Shooting it straight

Abraham Lincoln, or so the story goes, once asked: “How many legs does a cow have?” to which the reply came: “4”. President Lincoln then asked: “Now, if you take its tail and make that a leg, how many legs does it now have? 5?”

The software cow, by a wide stretch of the analogy, is based on deadlines, particularly code closures and releases. But by making the code closure date the release date, how many deadlines do we now have? With a cow, any cow in fact, it’s quite simple. A tail can never be a leg, even if you call it a leg. And it should be the same with software too. A release date can never be a release date if it’s actually a code closure date. Call it what you may, but it doesn’t change the reality of what it is, or isn’t.

Now, our real challenges take shape before we, the humble cow makers at your service, have even considered all the complexities of the legendary promised cow. The schedule for the project is conceived in advance by declaring one cow, four legs and a tail. Using graduate-grade financial analysis, and some logarithmic calculus for the more eccentric, deadlines for a functional cow are
established. Can moo. No chewing of the cud, but there’s 4 legs and a tail that will go “swoosh”, but only in version 2. From there, it’s up to the cow builders to deliver this promised bovine, on time. Now without taking any digs and waxing nauseously over the same age old arguments about who’s responsible for not presenting the 4 legged, tail-swooshing, cud-chewing beast on time, how is an idyllic XP-orientated world supposed to operate? And this time we’ll work forwards.

Build a cow. When you get to the part where it’s got 4 legs and a tail (don’t worry about the swooshing just yet), close the code. Based on that, testing can be scheduled; deadlines and release dates can be accurately planned. The nice advantage of living life forwards like this is that you can milk your cow at any stage. Simply set a code closure when you want to start selling. If at the time of wanting to sell, the cow only has two legs and subsequently walks around in circles, it does so by design. If you don’t think that will sell and want the 3-legged limp, but a good limp at that, then you have to wait for the feature is estimated before setting a code closure. A full 4-legged trot takes time. It’s impossible, no matter the methodology, to know upfront exactly, to a tee, how long any complex software will take to build. Which is great because as you build, you want the ability to adjust to constant change. Unless of course you want Retro-Cow, conceived in the 80’s to live in the 00’s because you couldn’t change the plan en route. We do have estimates though, but lets not forget the obvious. A 4 month plan cannot be real if the work is envisioned only 2 weeks at a time, and story should not be more than 3 days. You may have picked up on my use of the word “should”. What we tend to do outside of this resembles little of what XP is.

Plan ahead, line up the fence posts and work backwards from there. And being current, thus ensuring survival, demands constant change but without compromise on the boundaries, code closure and release dates start spiraling closer together. The full-bodied moo, plus some more moo, but all in the same timeframes. The knock-on effects of this I could however wax nauseously over for many moons. I’ll endeavour not to but team moral, duress, waning quality, stimulant dependencies, indecision and fear are just a few things bursting to mind. Everything we work so hard to establish and maintain become ‘ideals’ rather than the ‘reals’ they were a day before.

XP in development is only as good as XP upstream. It cannot just be a development methodology on its own. If the objectives that drive and sustain the business are not tied into XP “development” principles, how solid is the foundation for implementing XP? The real champions of XP have to be those that build the very foundations which drive and sustain the business. They’re the ones who have to be the most tenacious and ooze XP honesty, courage and maturity. They should be the real defenders of the methodology for only as much trust as they put into XP will water the branches. If our business strategies are not tied into XP, what hope do we have of development ever being based on XP? What’s really challenging is calling development XP but not living it.

It’s like being invited to play croquet on Sunday afternoon with the Queen, only to be confronted by 15 menacing All Blacks doing their hukka while you clutch ever so confusedly onto your bow tie wondering how painful it’s going to be. If we call it XP, let’s do XP, but the roots water the branches; never the other way round. But if we’re not going to do XP let’s call what we do something else so at least we can come prepared to the task at hand. What’s more important than any one methodology is that everyone agrees to build the cow the same way.