The road is paved with good intentions

There's an interesting discussion going on at Chad Meyers' blog about quality in both design and execution. Chad argues there is such a thing as Good Design, that knowledgeable observers can reliably discern its presence, and that "but it works!" is not a defense or justification for bad design choices.

The bad design characteristics Chad spotlights prevent teams from responding effectively to demands on the application. With each release the team is less and less able to respond until they are locked in to long projects that deliver little incremental value. How do teams start down the path that leads there?

Chad's post hinted at an important consideration that doesn't seem to get enough attention. Too often people make fast delivery of finished features the top priority, then define everything else as speeding up or slowing down delivery. The problem is that driving to "finished features" (where finished = fully realized) prevents the team from engaging in "fast fail, fast feedback" cycles. If there is also a stated desire to work in an "agile" fashion the team might try to marry the "finished feature" driver with a short-timebox approach with disastrous results. On a large project few fully-realized features can be started and delivered in a single 2-4 week period.

The Agile team will look for a way to decompose the desired end feature into meaningful chunks and distribute the work across the team such that each 2-4 week period delivers a coherent, complete piece of functionality. The wish-we-were-agile team calls on the team to keep the feature "simple," not to "gold-plate" it. Once headed down this path all kinds of things become gold-plating - error handling, usability, even the goal of working software can be set aside under the banner of producing "good enough" software quickly.

Of course there is nothing wrong with "simple," "good enough," or "rapid delivery." Problems arise when the team identifies "simple" feature realization and "simple" process with undesigned, untested and incomplete. The team might find itself choosing to hack up a feature, not because it's a justifiable approach given the business needs but because their inability to decompose the feature and plan across iterations has created an artificial pressure to cross the feature off the project plan. That team can report that features are "done" but pays the price later when the customer doesn't accept the feature or the market demands more.