Software is never done… Or is it?

The Agile Iconoclast gets things done

Combat fraud and increase customer satisfaction

The notion of doneness pervades everything we, as humans, set out to achieve. Want to send a manned rocket to Mars? It’ll be done when it’s done. Composing a new symphony? Can’t wait to hear the finished piece. Want to create a payroll system for an automotive company? Better deliver it on time, otherwise they might grow tired of waiting and pull the plug on the whole project.

head shot of Matt Stephens smiling

This notion of doneness exists for a reason. Without it, projects would just spin off indefinitely, and nothing would ever really be accomplished. There’s nothing quite like an impending deadline to focus the mind.

Doneness is a mindset thing: the dogged determination to deliver what the customer wants, and then move on to other things (be it a new project, or the next iteration of the same project). But as soon as you start planning for doneness, all sorts of complications snag up the nice clean concept of “job done”. Did the bug count exceed some arbitrary limit of project quality? Were individual features cut back to allow the project to be delivered on time? Was the latest feature-set delivered late?

Small wonder that, in IT, we have such a hard time with deducing what the customer wants and delivering what’s needed on time, and determining whether or not it was all a success. Software agility is a response to this quagmire of schedule uncertainty. There's much wisdom in the agile world; for example Mike Cohn’s book Agile Estimating and Planning is well worth a read, as it maintains an emphasis on focused delivery. It shows how to run an agile project without losing sight of the concepts of doneness, deadlines, and keeping to a schedule.

However, not all software processes are entirely compatible with deadlines: at least, not with a combination of fixed scope and deadlines. The Extreme Programming ethos, for example, is best summed up by agile guru Robert C. Martin’s posting to the now-defunct OTUG discussion group (October 2000):

“There is a difference between ‘Schedule’ and ‘The Schedule’. In XP, ‘Schedule’ is very important, but ‘The Schedule’ doesn't exist per se.

“The notion of having ‘The Schedule’ is related to the notion that a software project reaches a point where it is ‘Done’. The notion of ‘Doneness’ pervades our thinking and our communications. We say to each other things like ‘When this project is done…’ or ‘When will this project be done…’, etc, etc.

“The reality, of course, is that a software project is never done until it has been terminated. So long as the market is active, the project will continually evolve. Certainly it will reach points where it is releasable; but at each release there will be a whole list of things that need to be done to it.”

We dissected this quote and gave plenty of attention to its ramifications in Extreme Programming Refactored, so I won’t dwell on it here. To be fair to Robert C. Martin and to XP, a fundamental tenet of agile planning is that the dates are fixed but the scope may vary.

That is, the planned features may be dropped or pushed back to a future iteration, or, rarely, new features may be slipped in if there's time; but the actual delivery date for the current iteration will remain unchanged. You can see this not just in XP but in just about any agile process, e.g. timeboxed delivery in DSDM, or monthly sprints in Scrum.

But it doesn’t take a great leap of logic to flip the equation. If the question is “when will feature XYZ be delivered?” then “fixed date, variable scope” is roughly equivalent to “variable date, fixed scope”. Feature XYZ may be delivered in this iteration or it might slip to the next, so the delivery date for a specific feature is variable. It doesn’t answer to deadlines.

The real world is different: it runs on deadlines. For example, the new product must be on the shelves in time for the Christmas shopping season, or the new air traffic control system must go live by the year 8-billion; or the payroll system must be up and running for all employees in time for the new tax year.

In theory (and sometimes even in practice), agile projects are well set up to cope with hard deadlines. Perhaps the payroll system must be ready before year-end so all those P60s can be printed off and stuffed into little envelopes. So the team could at least ensure that the P60 printing-and-envelope-licking feature is ready in time, if not the complete system.

But the danger is that, with the XP mindset of software never being done and the schedule not existing per se, a meandering lack of focus can easily work its way into the project. At this point, the team loses track of the project’s long-term goals. Project managers focus on incremental delivery of features that are more about the project itself than about the real-world problems that they originally set out to solve; and the programmers, like pigs in mud, write unit tests and mock objects that give each other mutual kisses and cuddles.

They spend a day refactoring some code to a neater design pattern. They’ve got a green bar assuring them that everything’s okay. Warm fuzzy feelings all round; eternal sunshine of the spotless geek. And so the project spins away, immersed in its own issues, looking inwards on itself and forgetting to look outwards, until suddenly it’s cancelled and all involved glance up from their keyboards, wide-eyed and blinking.

This isn’t true of all agile projects; just the ones that have become tragically lost within the warm and fuzzy agile message. Of course, many agile projects successfully deliver small, incremental, tightly focused updates to happy customers and end-users.

The difference tends to be that in a successful project, the project manager (or customer/analyst, or architect, or lead developer) is a control fiend, a benevolent dictator, who never loses sight of the project’s original set of goals. With such focus, there’s invariably a fixed notion of doneness; some delivery criteria (even if the details may change); a point where you can look at what’s been accomplished so far and say “there, it’s done.”

Combat fraud and increase customer satisfaction

More from The Register

next story
Ubuntu 14.04 LTS: Great changes, but sssh don't mention the...
Why HELLO Amazon! You weren't here last time
OpenBSD founder wants to bin buggy OpenSSL library, launches fork
One Heartbleed vuln was too many for Theo de Raadt
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Got Windows 8.1 Update yet? Get ready for YET ANOTHER ONE – rumor
Leaker claims big release due this fall as Microsoft herds us into the CLOUD
Next Windows obsolescence panic is 450 days from … NOW!
The clock is ticking louder for Windows Server 2003 R2 users
Patch iOS, OS X now: PDFs, JPEGs, URLs, web pages can pwn your kit
Plus: iThings and desktops at risk of NEW SSL attack flaw
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
Apple inaugurates free OS X beta program for world+dog
Prerelease software now open to anyone, not just developers – as long as you keep quiet
prev story


Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.