Infrastructure-Oriented Computer Programming

The objective of infrastructure-oriented computer programming is to produce a tangible, executable framework at the outset. This holistic, strongly-prototyped, component-based approach allows components to be plugged together like Lego unlike traditional component development, which demands continuous or late integration to persuade the individual components to communicate. Integration painfully slowly reveals (and often fails to reveal) holistic problems such as deadlocks, race-conditions, log-jams etc., which may have repeat cycles of weeks or even months.

Contrast this with the house building industry; if a builder was tasked with building a house, he would not build, plumb, decorate and furnish each room separately and then attempt to 'glue' them together! Yet this is directly analogous to the integration approach (continuous or otherwise) adopted by the software industry at large.

Instead, any builder worth his salt would first construct a solid framework and test its structural integrity. Only then would he consider populating it with doors, windows, carpets, plaster, plumbing etc. Infrastructure-oriented computer programming prescribes the same approach for software.

This approach produces an executable framework early in the project lifecycle and this application is continually and holistically executable from that point forward. The framework provides the flow control for the application and populating the framework involves straightforward integration of pure processing code. This is a substantially more tractable process than integrating many components with each other, where each has their own piece of the flow control puzzle.

In order for the builder to successfully construct a structurally sound framework capable of being populated with the required items without subsequently failing, he follows the prescriptive blueprint produced by his architect. In creating that blueprint, the architect will have considered the requirements of the development and in particular all of the holistic issues (e.g. where to place the header tank to provide enough pressure for the shower).

Infrastructure-oriented computer programming also requires a prescriptive blueprint. Produced by the software architect from the project requirements and finely tuned with the customer, this blueprint captures the necessary detail for engineers to code an executable framework without significant further, high-risk inspiration. CDL is an excellent example of such a blueprinting computer programming language.

In addition, holistic issues that may lead to race-conditions, deadlocks etc. are considered at the outset and resolved prior to coding. An intuitive blueprint also provides an excellent vehicle for asking pertinent questions of the customer that they may not have even thought about and which impact their requirements. For example, what happens if a tape drive that is logging data initiates its head-cleaning process? do you want to block the whole system until it finishes, or start shedding data?