Another excuse for abandoning discipline . . .

Does Competition Justify Reckless Shortcuts?

by Conrad Weisert
May 3, 2010
© 2010 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.

The struggle for project discipline

We know how to plan and control a software development project. We've known how for decades.

Nevertheless, we keep seeking new excuses to set aside the rigorous disciplines of project management and good practice, and take risky shortcuts. First it was just urgency:

"I agree with you in principle, but this project is so urgent that we can't afford the luxury of following the methodology." —a 1971 data-processing manager.

That was usually accompanied by a promise to comply with the organization's methodology on the next project. Of course, the next project would be urgent, too, and the crisis-driven organization would never undertake a "normal" project (or a successful one).

Next it was the need to be "first to market" with a product or service. If the competition got there first, we could never catch up. That argument was further fueled by the public deployment of Internet-based applications. If another company gets there first, we argued, everyone will use their product and no one will pay attention to ours when we finally release it. The phrase Internet time became a justification for abandoning all discipline and even for deploying an application containing known bugs.

Products that got there first

To put the argument in context, it's helpful to review the history of software products or Internet services that beat their competition to market:

So, perhaps getting there first won't guarantee market dominance. Were the later products superior to the pioneering ones? Some were and some weren't. Marketing muscle has been the primary influence in a competitive market and is likely to remain so.

It's futile and counterproductive, therefore, to cite competitive pressure or "Internet time" as justification for abandoning all discipline in software development. In the interest of meeting a target date we may rationally decide to defer features, but we never need to produce or deploy "quick & dirty", sloppy, unmaintainable, bug-ridden software.

Return to table of contents
Return to management articles

Last modified May 3, 2010