"Good Enough" Software
“We have a tendency to define software quality only in terms of defects. We assume that fewer defects equals better quality, and we assume that the user always prefers zero defects. "Zero-defect" software is desirable for nuclear reactors, pacemakers, and air traffic control systems, but unnecessary, impractical, and even undesirable for many other applications. What users really want, especially in a corporate environment, are applications that are cheap enough, fast enough, feature-rich enough, and available soon enough - that is, "Good enough."
A software development team oriented towards "good enough" software has some very different behaviors and strategy than conventional IS organizations.
One characteristic of "good enough" software development is a utilitarian strategy based on risk analysis. We are engulfed by uncertainty in every second of software development. When was the last time there was a project that could not fail? If it really couldn't fail, weren't some of the resources or staff for the project more sorely needed elsewhere? In most situations, if we are on a project that can't fail today, tomorrow our project will be expanded, or our resources will be stolen. Efficient software development necessitates risk taking: the real question is whether we take calculated risks or accidental risks.
Another characteristic of "good enough" software development is an evolutionary strategy defined at the project, product, and problem levels.
On the project level, ongoing process education, experimentation and adjustment are instituted, rather than clinging to a notion of the One Right Way to develop software.
On the product level, development proceeds by planning and building the product in layers, which allows concurrent design, coding, and testing. It also provides opportunities to respond to changing requirements or unforeseen problems.
On the problem level, we keep track of history, and learn about failure and success over time.
Some of the elements of the evolutionary approach:
Don't even try to plan everything up front.
Converge on good enough in successive, self-contained stages.
Integrate early and often.
Encourage disciplined evolution of features and schedule over the course of the project.
Salvage, reuse, or purchase components where feasible.
Record and review your experience.
Dynamic infrastructure means that the company rapidly responds to the needs of the project. It backs up responsibility with authority and resources. Some of its elements are:
Upper management pays attention to projects.
Upper management pays attention to the market.
The organization identifies and resolves conflicts between projects.
In conflicts between projects and organizational bureaucracy, projects win.
Project experience is incorporated into the organizational memory.
Good enough software can still be achieved in the absence of a dynamic infrastructure, but mainly in the short run, and on the backs of an insanely committed project team. In the long run, the other process ideas will falter if saddled with the weight of unresponsive bureaucracy.
Dynamic processes are those that change with the situation; ones that support work in an evolving, collaborative, questioning environment. Three other important dynamic process attributes are portability, scalability, and durability. Portability is how the process lends itself to being carried into meetings, shared with others, and applied to new problems. Scalability is how readily the process may be expanded or contracted in scope. Durability is how well the process tolerates neglect and misuse. A final note about dynamic processes: the most dynamic process is no process at all. One popular and effective technique is to clarify project roles so that everyone knows who is supposed to solve what kinds of problems. Then, if the team works well together, peer-to-peer delegation can replace most orthodox processes. This "clarify and delegate" strategy is a good basis for all other dynamic processes.