Blank Page Syndrome

A recurring theme that came up during almost every session was a criticism of the attitude we inherited from the early days of computing in which the ideal situation is to be faced with a challenging new problem and a blank page on which to design the ideal solution. This leads to two too-tough problems:

• the impossibility of master planning - that a fixed set of requirements exists that once addressed yields an ultimate solution. In the real world though requirements are constantly changing and any program designed for a single point-in-time will be inadequate. Worse brittle system architectures make later modifications difficult or impossible.
• the impossibility of total control - the temptation to play God, to try to take a pure, ideational world and add something new to it and then place the resulting "perfect " thing in the world with only the ideas and work of one individual or team being the sole determiner of everything in that software. That is, this is the temptation or conceit that a single person can and should create an entire system and that it would even be possible to do it, to hold all of those things in one head long enough to get it right. What happens is that such an endeavor fails to take adequately into account the larger, ever-changing context in which the software will exist; this failing is the failure of conceit. Further, such a conceit tempts one to think the creator - designer and coder - has total control over the context and software so that, were there only time enough, the result would be, and could be, perfect.

The result of holding a belief in the perfect blank page is the idea of "static design" (and perhaps of many other infestations of the concept of staticness in computing) in which once perfection is attained, the result can be handed to the world which can use it as is.

Unbridled hubris.