Beyond "late" software

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.

Embracing Late

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

Managing the Trickle

The focus of value on a “releasable product” is important. Every iteration we what to ask, “Does the product have enough capability to release today?” We want to focus on this strategic value question, not on whether every detailed requirement (scope) has been implemented. By focusing on detail requirements we lose strategic focus. —Jim Highsmith

It’d be nice to figure out some rule of thumb for bundling releases taking that overhead into account. Then, of course, you can focus on optimizing that overhead to grind down release windows. Also, I’m not sure there are good rules of thumb for figuring out when it’s OK to release “late” in the name of quality or completeness.

At a minimum you could start with a “zero budget” approach. Start with one feature and ask “is this enough ‘strategic value’ to release? No? How about if we add the next feature…” and so on.

Whatever the case is, most Application Life-cycle Management tools don’t seem to support this type of managing. In a cloud world, there’s theoretically ways to better assess the value of any given feature:

• Access to user tracking to figure which features of an application are users access most (or least!). Then, predict future feature value based on past an present and narrow down your release accordingly.
• Limited releases of “less than perfect” functionality to see if a sub-set of users would find value in those features, and then finish them off to perfection. Here, you’re doing the equivalent of focus groups to shape the final release. The difference with cloud-based delivery is that the mechanics of this should be easier and cheaper than on-premise and packaged applications. So you can do more of it, more frequently, and hopefully make better predictions.
• Even “crude” surveys of users’s desires, instead of primarily talking with buyers through traditional sales and product management channels.

To make the release-slicing decision, you need tools that provide a fair amount of data about how your software is used and release management tools that let you experiment with features.

The negative consequences of being on-time

The old cliché of the the Toyota Production System allowing any worker to shut down the line fits in here, of course (check out a recent This American Life for an excellent, fresh take on TPS). The consequence of too much pressure to “keep the line moving” (ship on time, for software) can result in crappy software, either through bugs introduced due to speed, general sloppyness, lack of QA and/or users not liking what they get…and motivating them to look at competitors.

Making the release date has been an unmovable requirement for as long as I’ve been in software. When new methods of software delivery come along, it’s worth re-thinking core assumptions like schedule. At the very least, it’s a good idea to refresh yourself on why your given piece of software has to be on time, or if it can move beyond being “late.”

Disclosure: Microsoft and SAP are clients.