Rob's Software Engineering Logbook

Common Sense applies to Software Engineering?

Surely, it is foolish to believe that sense in the software community is common. There may be common axioms that provide a framework within which to develop... though adhereance to these is often the exception, not the common practice. But that is neither here, nor there. That particular view of common sense is *not* what I aim to discuss in today's Logbook.

The view of Common Sense we'll examine here comes from Mr. Thomas Paine circa 1776. Specifically, Paine makes a point related to the topic of complexity that has been addressed lately by the Simple Accessible Code (SAC) priciple proposed by Professor Gregg Vesonder, and tangentially by Using Simplicity to Control Complexity by Lui Sha.

In his pamphlet, Common Sense, Paine wrote:

I draw my idea of the form of government from a principle in nature which no art can overturn, viz. that the more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered; and with this maxim in view I offer a few remarks on the so much boasted constitution of England. That it was noble for the dark and slavish times in which it was erected, is granted. When the world was overrun with tyranny the least remove therefrom was a glorious rescue. But that it is imperfect, subject to convulsions, and incapable of producing what it seems to promise is easily demonstrated.

Absolute governments, (tho' the disgrace of human nature) have this advantage with them, they are simple; if the people suffer, they know the head from which their suffering springs; know likewise the remedy; and are not bewildered by a variety of causes and cures. But the constitution of England is so exceedingly complex, that the nation may suffer for years together without being able to discover in which part the fault lies; some will say in one and some in another, and every political physician will advise a different medicine.

For the sake of discussion in the software domain, which Paine obviously had no knowledge of, I would like to restate this in the words which make them relevant to software...

I draw my idea of the form of software from a principle in nature which no art can overturn. The more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered.

With this maxim in view I offer a few remarks on the so much boasted state of the industry (particularlly any project with SLOC in the MILLIONS). That it was noble for the dark and slavish times in which it was erected, is granted. When the world was overrun with assembly language the least remove therefrom was a glorious rescue. But that it is imperfect, subject to convulsions, and incapable of producing what it seems to promise is easily demonstrated.

Complex Source Code, (tho' the disgrace of the software world) have this advantage with them, they are maintained by a single organization; if the people suffer, they know the head from which their suffering springs; know likewise the remedy; and are not bewildered by a variety of causes and cures. But the source code of a MILLION LINE PROJECT is so exceedingly complex, that the developers may suffer for years together without being able to discover in which part the fault lies; some will say in one and some in another, and every software architect will advise a different medicine.

Therefore, I echo the words of Professor Vesonder, that, "developers of software systems should be able to understand the complete body of code in their systems." Clearly, this is not possible when SLOC approaches a million lines and when design documents for a single project fill a bookcase. When this happens, change is not only necessary, but it is inevitable.