My tolerance for complexity — in all things — seems to be decreasing with age. And I don’t believe it’s the onset of dementia. Quite the contrary, I attribute it to wisdom gained with considerable experience

Brian Kernighan, one of the authors of the ‘Unix’ computer language, wrote:

Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Computer programs always have some degree and complexity, and usually are not exactly correct.  They are born with “bugs”, and the task of debugging is about finding those flaws of logic that lead to wrong behavior in certain — perhaps unusual — cases.  If the program is written in a clear straightforward manner, with visible structure, and an appropriate number of explanatory comments, the debugging process will be much easier.  But if the program is written with clever tricks — perhaps taking advantage of some esoteric facts about the number system — debugging will be difficult or, as Kernighan suggests, impossible.

I used to travel widely, delivering to computer programmer audiences a talk entitled “On being lazy, absent minded, and a great system developer”.  I explained that being lazy meant that once I’d developed some code that worked, I’d take time to document it carefully, and package it so that it could be re-used in other larger programs in a natural way.  Thus I would do something well, once.  Being absent minded meant that I’d often lose track of where I was in the coding or development process.  To compensate, I’d have to write a plan first, and document any changes to that plan as I proceeded.

With these definitions, all the developers and analysts in my audiences could affirm that my qualities of laziness and absent-mindedness — as I compensated for them — were excellent qualities!  In fact, what I’d spelled out are two best practices for writing code.  A program consisting largely of well written and already debugged small sub-programs will almost always be more reliable than one written as a new mass of virgin code, and intelligent comments are an important compliment to the code itself.

I asked my audiences for a show of hands, how many spent much or most of their time debugging or updating other people’s code.  Most raised their hands.  Then I  asked how many found that code to be unclear, unstructured, hard to read, and difficult to  modify in a safe reliable fashion.  Again, most hands went up.  Finally, I asked how many were rewarded in their performance review for writing such high quality code — instead of just for writing lots of lines of code that seemed to work.  This time the hands stayed down.

Evidently, although we recognize that complexity is almost unmanageable, we’re too often unwilling to invest in simplicity.  And simplicity is the product of good design.  I believe that the underlying issue is our reluctance to understand the importance of design.

I’ll have more to say about this in future posts on this blog.