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.

One thought on “Realistic development ambitions”

  1. This provoked a couple of thoughts:
    (1) Having narrow, well-defined goals, but the technical difficulty of closure is not well anticipated. The approach is clear in the large, but, being unable to anticipate the range of inputs/outputs to be handled, causes a large delay. Prototyping doesn’t necessarily enlighten you about this.
    (2) Completing functionality is much more rewarding the investing in testing, until the lack of robustness of the functionality is so painful, and the results of testing, knowing what works, is even more rewarding. Fixing all the failing tests can be an open-ended endeavor, so how do you decide when enough coverage is sufficient for release, leaving known failures.
    (3) The distribution of inputs/outputs has a long tail. What happens when the distribution of what is used is not the same as the distribution of the inputs/outputs? That is, actual use is significantly populated in the long tail? In that case, you have a hard problem. And how do you anticipate this?

Leave a Reply to John Kulp Cancel reply

Your email address will not be published. Required fields are marked *