The lure of interesting problems

We can all get caught up in solving interesting problems – even when simple alternate solutions are staring us in the face. Example:

A program that had been running as part of a financial application since 1992. In the year 2000 I was asked to change the program so that it output a precisely formatted document alongside it’s existing functionality. As the program was running on a VMS system this document had to be achieved using ASCII character output only – so that left PostScript as the obvious option even though I knew nothing about it’s syntax. As one of the techies at that business had a PostScript manual of sorts at the back of a shelf I learned enough PostScript to produce the document – although I wisely appended a long description of how this had been done in comments within the program – a message to myself or anyone who followed. Seven years later – up popped a bug. How wise had I been? – well not very, as it turned out. The document output contained a name and an address and it had become customary among those running the system to use brackets within these fields – something like “United Consolidated Industries (trading as ACME)” perhaps.

Anyone who knows anything about PostScript is already laughing and (correctly) classifying me as a hopeless beginner. Let me explain. Text strings in PostScript are enclosed within brackets. Matched pairs of left and right hand brackets within those text delimiting brackets are treated as part of the string. The bug, of course, was the first time that an unmatched bracket turned up within such a string. This completely “threw” the PostScript interpreter of the printer and all subsequent output following the error was ignored.

It gets worse though. I had been doing a few things that week that involved parsing strings. So right away I saw this as a parsing problem. I wrote a function that used an array as a “stack” that parsed each string at risk – ensuring that only matched pairs of brackets – no matter how deeply nested – reached the PostScript print file. A neat elegant solution that I was feeling quite warm about until I started to laugh. The common sense bit of my brain had at last got my attention and pointed out that PostScript must have a string escape character and that it was probably the backslash (these things tend to get copied from one domain to another). Of course common sense was right as a Google search quickly confirmed (I told you I did not know any PostScript) – the true solution to the bug was simple and pragmatic – but nothing like as interesting as my function.

So apart from persuading potential customers that my consultancy services are to be avoided – is there any point to this little confession? If we can get caught up by an interesting problem (in my case) to the point of missing the obvious then might that apply to larger software architectural building blocks as well – perhaps even to whole systems. Yes – I am alluding to my post of last week that touched on the “Big Ball of Mud” (BBOM) pattern and it’s place as a de-facto standard for software architecture. Remember – systems based upon that pattern can be long lived and prove cost effective – above all they number among the projects that made it to implementation. A great many projects never make it. It is held that a common cause of project failure is a lack of good design – and I am assuming for the moment that proponents of “good design” are unlikely to include the BBOM pattern in the category of “good”. Might a deliberate lack of a coherent design in fact be good design? Are there characteristics of successful (defined as implemented) BBOM based systems that support their success and differentiate them from the (sometimes elegantly designed) failures that never make it into production? I suppose I am wondering if there is good design deep within the BBOM pattern – or is that just too inconsistent a thought – even for me?