Realistic development ambitions

When defining goals for a startup, or outlining requirements for significant new software development, a lot of things pressure us to be too ambitious. A little stress is energizing, but striving toward unrealistic goals is both damaging and wasteful.

Pressure

It’s a proud and noble thing, setting out on the hero’s journey, to slay the dragon or strive against the odds, to dream the impossible dream. As Shaw wrote, “all progress depends on the unreasonable man.”” Steve Blank speaks of “crazy entrepreneurs” who are hallucinating, yet sometimes are actually visionaries.

So to get going it is necessary to have iffy judgment!

We get off to a rousing start. We don’t want to miss the best ideas, so we solicit and collect all the ideas. It’s perfectly appropriate to gather up and consider every possibly relevant feature, enhancement, performance improvement, what have you. That’s even a little like brainstorming.

Of course nobody wants to see their good ideas shot down, so everybody pushes for their favorite feature to get crammed into the next release. The pressure is exacerbated if the organization has a, ahem, mixed record of getting releases out the door. When releases are few and far between, every stakeholder pushes for their items, believing that the upcoming release might be the only window of opportunity for that great idea or that great customer.

Then if the release date is slipped, especially when there’s a history of slips, it’s taken as a reprieve, a second chance for all those ideas that barely didn’t make the first cut, a chance to crowd more orphans aboard the overloaded, struggling train.

Downfall

In responding to that pressure, we overpromise. Then when it all hits the fan, we’re forced to underdeliver. Or else we rush heroically, sacrificing our health and our relationships, to squeeze out something precariously undertested and embarrassingly unprofessional. Dang.

Underdelivering damages credibility, both our own within the organization, and the external credibility of the organization itself. It throws into disarray other things that serially depend on it, like maybe a long-lead-time marketing campaign. And it leads us to misdirect or even waste our scarce resources.

What does it mean for something be a requirement for a release? The effect is that everything else in the release, done or not, has to wait until that something is finished. Everything else gets held back, ready or not, impatiently tapping its toes and rattling its fingernails, maybe growing stale, until the last bottleneck slow-poke finally finishes.

Slip

Or maybe there’s a change in the pressure equilibrium. With fixed resources, there is a mutual tradeoff among schedule, scope, and quality. Under irresistible schedule pressure, either scope or quality will suffer.

We can shrink scope by dropping some stuff from the release, unfinished or maybe even almost finished, freeing everything else to ship. Or maybe quality will suffer, if it seems that rushing to ship crap on schedule is better than to ship nothing at all.

Creative goal reduction (dropping late stuff from a release) is actually a tragic thing to have to do. All those resources, effort, planning, energy, were invested in something to not ship? What if resources had been focused on a subset of the goals, getting those out the door that much sooner? True, this can’t always be done — neither projects nor developers are truly fungible — and you can’t produce a baby in one month by assigning nine pregnant women to the task.

As far as quality goes, why do we have to choose between shipping something half-assed, or something that’s competently done yet obviously incomplete? Are those really our only options?

We don’t explicitly plan to do things that way, but when it arises naturally out of our plans, we can’t duck the responsibility.

I do have some ideas for one way out, which I’ll save for a future post.