Feeds

Software is never done… Or is it?

The Agile Iconoclast gets things done

SANS - Survey on application security programs

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

High performance access to file storage

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
IRS boss on XP migration: 'Classic fix the airplane while you're flying it attempt'
Plus: Condoleezza Rice at Dropbox 'maybe she can find ... weapons of mass destruction'
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
New Facebook phone app allows you to stalk your mates
Nearby Friends feature goes live in a few weeks
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
prev story

Whitepapers

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.
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.
Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
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.