Editorial: A Glimpse Behind the Scenes

This summer I went walking in the Lake District with my girlfriend, and on one of the days we found ourselves walking through a mist that reduced visibility to around 10 metres. Unable to use other mountains as reference points (or, indeed, much of the mountain we were on) we were reliant on a compass and dead reckoning. Despite our best efforts we eventually found ourselves on a scree slope with no sign of a path. We were not exactly lost - we had a bearing to follow and would eventually reach landmarks and a path leading us to our destination, but the going was slow and difficult.

While we were debating where we'd missed the path a voice came from the mists hiding the top of a near vertical rock face "you shouldn't be down there - the path is up here". While that gave a point of reference, it didn't solve the problem of how to proceed from where we had arrived. We had gone wrong, but we had company: another group of people arrived and by all sharing the results of exploration we found a way forward that eventually rejoined the path.

This story does have relevance to Overload but, before explaining the connection, I'm going discuss a little of what happens behind the scenes to produce the copies of Overload that arrive for you to read every couple of months. You have probably guessed a part of it, but the issue that I want to address is one that rarely makes an explicit appearance in the journal:

Usually the review by the advisors is uncontroversial, but occasionally an article generates real debate. When considering Jeff Daudel's article "A Unified Singleton System" (Overload 56) there was such a concern over the content of the article that the editor (then John Merrells) was moved to include an editorial comment. And, in the next issue, one of the advisors (Mark Radford) wrote a balancing article "Singleton - The Anti-Pattern!" (Overload 56).

Such debate is rare, most articles present material that the whole editorial team is happy with. However, it has happened again (but on a lesser scale). One of the articles published in the last issue moved one of the advisors, Phil Bass, to email me re-iterating the concerns that he expressed about the article when first presented. I could have relegated this to the "letters" page but, by implication, it raises issues of editorial policy that I feel should be discussed.

First here is what Phil Bass has to say:

OK, here we can see real concerns being expressed about the article. So why then did I choose to publish it without comment? Well, partly because the other advisors and I don't share these concerns.

While we agree with Phil that it would be better to have avoided arriving at the problem, people do get to this point and don't always have the opportunity for a "fundamental restructuring of the system". It is more helpful to facilitate the communication between such people than to take the part of the anonymous voice saying "you shouldn't be down there". It may serve as a warning to avoid retracing the steps that lead to the situation, but doesn't address the tactical problem of dealing with it.

Maybe I was wrong. I can imagine that some Overload reader somewhere is facing the problems described by Allan Kelly. They probably know they have problems, but upon reading the article they may get the impression that the solution presented solves the underlying problem and not only the symptomatic one. This too is a pattern "Shifting The Burden" - described by Peter Senge in "The Fifth Discipline" (an excellent book on organisational problems). "Shifting The Burden" is a bad practice or "anti-pattern" largely because by failing to address the true causes of a problem, but giving the appearance of fixing it, it encourages the problem to grow to proportions that make an eventual solution problematic.

Maybe I was right. I've used "Encapsulate Context" in the past - albeit long before reading the article. I took an application that had, scattered throughout its code, snippets of code that went to various sources of configuration data (the Windows registry, the command line, several databases, configuration files) and moved all of these snippets into a context object. This made it far simpler to test components (we didn't need to set up copies of all the sources of configuration data for each test). When additional configuration data was required by some new code, it was clear how to obtain it - from the context object. And the difference between live and test configurations became easy to parameterise. Even the author of the original code was impressed by the changes. That system is still running and being developed and - as of the last report - without suffering the high maintenance/low testability problems that are a risk of such highly-coupled approaches.

There is a fine line to be drawn here and, while I think that we got this one right, it is necessary to be vigilant. The role of the Overload team is to help the author present tools and techniques that may be of use to the reader and let the reader be the judge of when they are appropriate. I expect readers to use their judgement when considering the application of such ideas - they should know that there are always trade-offs. Knives and forks can be dangerous, but I don't insist my children eat with blunt sticks. And the lesson I take from my experience in the Lake District? While it is good to know where one should be it is also worth listening to the people solving the same problem you have encountered where you are.