Is it time to stop worrying about software being “late”? Cloud-inspired software delivery muddles the idea of a fixed release date, making the concept of late software difficult to pin down.
Running a Deficit
Managing “technical debt” has been an interesting conversation in some parts of the Agile community of late. Technical debt is a nice way of accounting for “things we should have done, but did not in the interest of releasing sooner.”
In this context, and with the new software delivery functionality that cloud computing might offer, it’s worth looking at another question as well: What’s the cost of releasing software late? That is, we always assume that software has to ship on time and tend to build the development process around that one constraint. It’s often said that there’s an Iron Triangle of project management, usually composed of some mix of cost, functionality, schedule, and quality (yeah, the metaphor breaks down).
In reality, schedule is more like The Unmovable Requirement. The software must always ship on time.
In traditional software, being late is bad for several reasons, all revolving around reliability and trust. If “the market” thinks you can’t deliver software at the promised date:
- Users/customers putting your software into their plans and budget don’t want to deal with you. In the worst case: this means you can’t rely on revenue spikes when you deliver software, making your income non-predictable. For a publicly traded company, this is terrible as that bastard “The Shareholder” only rewards predictable companies.. For a smaller company, it means an annoying boom-and-bust cycle.
- Competitors may cement their position before you do. While you’re rotating on the scope and quality portion of the Iron Triangle, someone else gets their software out and your “marketplace” goes to them rather than you.
On the second point, many tech-world darlings are a counter example to this. Apple’s late release of the iPod in MP3 player and the iPhone in smart phone markets; Apple waited to get the perfect devices out and then dominated in saturated, moribund fields. Google search, email, etc. as well. Milage may vary: I’m not sure the enterprise would have that tolerance, but maybe that’s part of the problem with enterprise software: not being able to wait for the software you want, instead burning piles of case on the software you have.
Also, I wonder if the dynamics of “on-time” change with SaaS/cloud-delivered software. I’d wager they do. That is, people will complain that Foursquare, Google Reader, etc. haven’t “done anything” for some term (Yahoo!’s del.icio.us is a frequent, though niche example), but people don’t really attach the scorn of “late” like they would if, for example, Windows or SAP’s Business ByDesign is delivered late.
The well-worn and referenced example of flickr’s “10 releases a day” sketches out the utopia here. Drastic technological and cultural changes are needed, of course. When you give your users a steady trickle of features, the concept of “late” and “on-time” seem to become fizzy.
Personally, getting a trickle of features out the door is more important to me (as a user of any given software) than getting on-time (larger) releases. “Late” is relative to each user’s desires: something is only “late” to me if I don’t have it right now.
Of course, there are draw backs: perhaps the QA that goes into a “micro release” is so high that you can’t just release “a feature” affordably. The marketing efforts too may be too much. Thus, to control those costs of time and money, you want to bundle up releases…