Clamberry Blog

Our team recently brought in a consultant to review our project’s architecture, examine our goals and assess our strategies in moving forward. In our discussions, we discovered that some of, what we thought to be, our thornier problems were not problems at all. Rather than complexity that is intrinsic to the application, we introduced complexity by assuming a need for concurrency and then added complex locking to control that concurrency. In truth, the application did not require that concurrency, i.e. a process that runs in a parallel thread. It was perfectly OK, to just run that process when needed. Rather than a massive parallel task on all data, we could simply have a small, very quick task that operates synchronously on a single object at the time it is changed.

The details are not really important. But the take-away is that we are often the victims of our own exaggerated sense of complexity. As an architect with whom I once worked observed – when a solution seems too complex and you find yourself layering on complexity to handle issues that your solution presents, then it is likely a time to look for a simpler solution. Sure, sometimes things really are hard. But often the hardest challenge is to find the simplest answer. As Blaise Pascal famously said, “I have made this letter longer than usual, only because I have not had time to make it shorter” [1].

So it is with software. Simple is better, but not easier. Taking code away has more value than adding lines of code. And often, the best thing you can say to that code over which you slaved and are trying so hard to fix is “goodbye”.

Another lesson from this exercise is that often the most important thing a consultant can offer is a truly objective perspective. With no vested interest, ego investment or pre-conceived ideas, the most useful thing they can do is ask “Why?”. And, often, the most useful ideas surface not through the value of the answers but the importance of the questions. If you don’t focus on the right questions, you are likely to arrive at the wrong answers.

Tell it to the duck

Often, when debugging, we bring in a peer to help us figure out the problem. I find that, very often, just through the process of explaining what is happening to a colleague, the problem becomes more clear. This process has been described as Rubber Ducking [2]. We don’t need someone else to help us as much as we need to be forced to articulate aloud what is happening. Just that articulation is often enough to help us step back and see the problem. Now, I do have to say, our consultant was a lot more insightful than a rubber duck. But, often, articulating our architectural decisions and explaining them brought to light unnecessary assumptions that overcomplicated and caused problems for our design.

Sometimes the toughest problem may be in recognizing that there is no problem at all.

1. This quotation is often mistakenly attributed to Mark Twain [http://www.twainquotes.com/Letters.html].

2. The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and DavidThomas, p. 95.