Thinking outside the box

Today's rant was inspired by an article in the most recent CACM, Wanton Acts of Debuggery | February 2012 | Communications of the ACM. But the article really just offered me a good jumping off point. The article discusses the habit of some coders to create some really inane messages for debugging or exception conditions. Of course I agree. But I don't really think the author gets to what is the deeper and ultimately the more interesting issue. We are so focused on the primary functionality of the module that we are only peripherally aware of the number of important relationships that exist between the module and potentially many other modules in the system.

Below is a brain teaser I first saw more years ago than I'll every admit. It was used in an innovative series of ads for a company I can no longer remember. The point of the brain teaser is to connect the dots with four straight lines without lifting your pencil from the paper. I'll give the answer later. But join me again below the image.

There are nine obvious rectangles that can be formed in this image and one more that is arguable. This brings me to where my mind went and why these two things are related. 

A point that Bass et al make in the book, Software Architecture in Practice is that UML diagrams often encourage the denigration of the relationships between the modules. The single line that is often used tends to suggest that the relationship between the modules is somehow simpler than the modules themselves. This may have been true once but it certainly isn't true in the more complex systems. The relationships need far more attention than a simple line can convey.

The CACM article focuses on the exception messages from a module which are directed at the programmer who will use them to diagnose the fault. However in a fault tolerant environment, these messages must be received by some module other than the one processing the transformed data is directed to. Control and data travel different paths.

A quality that must be exhibited by some modules is testability. Instrumented code creates another stream of messages that is distinct from the control messages and data messages. And none of these channels need to be one-way nor do they need to implement simple protocols. The relationships between modules and the interaction of these simultaneous communicating processes presents challenges to predict all possible states.

The point of the brain teaser above was the necessity of allowing the lines to extend beyond the assumed box defined by the outermost points. The box that can be argued as the 10th box defined in the puzzle is the one that encloses all the white space which surrounds the points. I think the implied box which can be easily forgotten represents the broader system requirements. And I think the complexity and importance of the relationships between these modules is overshadowed by the processing modules.