Software is never done… Or is it?

The Agile Iconoclast gets things done

Remote control for virtualized desktops

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.”

Secure remote control for conventional and virtual desktops

More from The Register

next story
PEAK APPLE: iOS 8 is least popular Cupertino mobile OS in all of HUMAN HISTORY
'Nerd release' finally staggers past 50 per cent adoption
Microsoft to bake Skype into IE, without plugins
Redmond thinks the Object Real-Time Communications API for WebRTC is ready to roll
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
Mozilla: Spidermonkey ATE Apple's JavaScriptCore, THRASHED Google V8
Moz man claims the win on rivals' own benchmarks
Yes, Virginia, there IS a W3C HTML5 standard – as of now, that is
You asked for it! You begged for it! Then you gave up! And now it's HERE!
FTDI yanks chip-bricking driver from Windows Update, vows to fight on
Next driver to battle fake chips with 'non-invasive' methods
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Ubuntu 14.10 tries pulling a Steve Ballmer on cloudy offerings
Oi, Windows, centOS and openSUSE – behave, we're all friends here
prev story


Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
New hybrid storage solutions
Tackling data challenges through emerging hybrid storage solutions that enable optimum database performance whilst managing costs and increasingly large data stores.
Reducing the cost and complexity of web vulnerability management
How using vulnerability assessments to identify exploitable weaknesses and take corrective action can reduce the risk of hackers finding your site and attacking it.