Fitting Process into Internet Time

By Jeff Gainer

(Author's note: This essay originally appeared in the 10 January 2001 issue of the Cutter IT Journal E-Mail Advisor.)

by Jeff Gainer

Despite the sagging NASDAQ, things at a lot of dot-coms I have visited recently seem to humming happily, frantically along. There are countless meetings, never enough conference rooms, hurried conferences on the way to those meetings, and the really frantic are zipping by on those ubiquitous, obnoxious little scooters. Meeting deadlines depends, more than ever, on working overtime, as market pressures and impatient investors demand to finally see some revenue from those nifty new ideas. And every time, it seems, it is the individual heroics of super programmers who manage to pull it off just in the nick of Internet time.

In the first edition of the Capability Maturity Model, Watts Humphrey observed that "There is a common view that a few first-class artists can do far better work than the typical software team. The implication is that they will know intuitively how to do first-class work, so no orderly process framework will be needed." He points out the wrong-headedness of this view, noting that "Successful software organizations have learned that even the best professionals need a structured and disciplined environment in which to do cooperative work… First-class people are essential, but they need the support of an orderly process to do first-class work."

Herein is the central problem of software development on Internet time: most organizations build software without understanding why they are or are not successful at it. They continue to develop products the same way, relying on the individual heroics of those super programmers. If some of the super programmers leave, they take with them the qualities that made the organization successful. Moreover, the super programmers are successful not just because of raw intellect, but because they perform - consciously or otherwise, perhaps from habit - work practices that can benefit the average programmer.

Sadly, I fear that future managers of software development will not have much to learn from this era, unless it is this: from time to time, slow down and analyze, reflect. Bring back the old project post-mortem, or perhaps an Internet-age version of it. Rather than conducing a formal project analyses, I frequently urge clients to conduct mini-post mortems: informal, unstructured chats about what went well and why, and what they would, hopefully, never repeat again. These meetings take place in conference rooms, over someone's cube wall, over lunch, walking to another meeting, or even the bar at the local Sheraton. Then someone (usually me) types up the notes into lessons for all to see, review, and learn from.

--Jeff Gainer


(c)2001 Cutter Information Corp. All rights reserved. This article has been reprinted with the permission of the publisher, Cutter Information Corp., a provider of information resources for IT professionals worldwide.

This article originally appeared in the Cutter IT E-Mail Advisor, a supplement to Cutter IT Journal.

Return To