For business software, faster-cheaper can be better too.
Can you get faster engineering development, better product quality, and cheaper production costs all at once? NASA pushed this line aggressively in the last decade and wound up with a disastrous, credibility-busting string of space mission failures. The agency has sworn off the faster-better-cheaper bottle and now drinks the conventional brew that promises all three of these attributes at once on a project -- provided you settle for getting only two of them at a time. Businesses develop software under an identical "take two of them at a time" assumption.
The assumption is wrong. Business software built quickly and cheaply can be a better product, provided "better" is defined as delivering more utility and value to its users.
NASA produces a class of software known as "hard real-time." Real-time software responds interactively to its environment, which it monitors through sensors. The speed of the response is critical, and the fact that it is called "real-time" should clue you to the deadline of the expected response. Hard real-time software takes this concept to the extreme -- the software is guaranteed not to fail. The software controlling the robots on an assembly line is typical hard real-time code: if a robot miscalculates its response, it might fail to bolt an engine to its frame. An anti-ballistic missile shield is another example, as is a spacecraft landing-control system. In each case, a failure scrubs everything. It makes sense not to stress faster-better-cheaper under real-time conditions and NASA's original decision to proceed otherwise under hard real-time conditions was a lethal analytic blunder. This was, after all, rocket science.
Business software is different. Contrary to the blink-of-an-eye combat and sports analogies touted by executives and consultants, business proceeds at a leisurely pace relative to the processing speed of a computer. The best business software is produced at low cost and discarded quickly as new revisions and better competitive versions appear. The worst business software (a) requires a long development cycle, which increases the odds of it referencing an outdated environment and delivering outdated responses to that environment, and (b) is so expensive that its users have disincentives to dumping it for something better.
Unless a business is in a mature, static environment, long development cycles and expensive code expose it to the risk of running products that produce irrelevant results. A program that takes 20 months to build, for example, encapsulates a nearly two-year-old model of how the business works. A business within a dynamic, rapidly changing environment may malfunction when it consumes and acts on the output of this stale product. The worst casualty of long and expensive cycles, however, is the lost future value from improvements and innovations not undertaken because the code base costs too much to change.
Fresh code is better code, but surely all of this upgrading and replacement will frustrate and antagonize the users. Here, too, the assumption is wrong. Churning the code base to make it better need not disrupt its end users. They won't even know it is happening. How?
Contemporary software design emphasizes a modular construction where the various modules communicate using a standardized, stable vocabulary called an "API" (application programming interface; the software is the "application" and the vocabulary is the "programming interface"). The care that programmers apply to creating this vocabulary when they initially design a piece of software corresponds closely to the final quality of that software.
The chief feature of this design style is that it isolates programmers working on one part of the software from changes made by other programmers working elsewhere in the software. If one module requires a "sort," for example, regardless of how programmers implement that sort and regardless of how often they modify the sort procedure, any call to the sort module will work fine. The calling modules never deal directly with the changed code; they deal only at the level of asking for a sort.
A short way of describing this chief feature is to say that an API tightly controls the degree of abstraction needed to use the software. Asking for a "sort" serves as a semantic barrier, eliminating the need to specify, in many words, the exact details of conducting a sort. This is a very powerful idea.
An extension of this chief feature is that these abstractions can be grouped into higher level abstractions. Good APIs are built of small elements that compound. A word processor, for example, might have an API that lets someone "open" a file, "add" to its contents, "save" the additions, and "close" the file. These little elements easily compound to a larger "edit" function. When a programmer requests an edit, they save the time and space needed to say "Open the file, add to it, save it, and close it." APIs are not only efficient, they are extensible as well: when entirely new procedures are required, a term is simply added to the API vocabulary.
If the software is designed with a final layer of abstraction at the level corresponding to the interface where users interact with software, then any changes taking place below this layer are transparent to, and do not disturb, the end user. This top-layer API vocabulary is sweetest when its collection of terms closely mirrors those used by the business practitioners. At that level, its compounded elements are often referred to as "objects."
Using these concepts in an organization allows rapid innovation to occur below a more stable layer of behavioral API terms. All the users ever experience is the active vocabulary of the organization as expressed by the software they use ("Click here," "If this is what you want, select 'Yes,'" and so forth); below this abstraction layer the procedures -- the business logic -- quickly adapts to a rapidly changing environment.
Business software is a commodity that must be produced fast and at low cost, modified frequently, and trashed quickly as situations change. Full-featured scripting languages such as Python, as opposed to compiled and quasi-compiled languages such as Java, are ideal for this heavy rotation production because they allow rapid, robust software development by less skilled (less expensive) programmers. This all can be accomplished without disturbing the smooth operation of the business. And none of it takes a rocket scientist to accomplish.
William Paul Fiefer publishes Webs in suburban Chicago. Visit him at http://www.prairienet.org/~yamada and contact him at firstname.lastname@example.org.