Why am I writing the editorial?
Six years ago I edited a single issue (19) of Overload to bridge the gap when the then editor (Sean Corfield) gave up the job and we were seeking a new editor. On that occasion I edited a single issue on the understanding that I would not be able to continue and in the hope that someone would be able to take over. Fortunately John Merrells volunteered to edit the next three issues and, as you will be aware, he is still here!
In the editorial of "my" issue of Overload I admitted that I'd like to be able to do the job on a long term basis but, at that time, there were too many demands upon my time for me to make that commitment. I even went so far as to say that it would be a possibility "in a few years". But, in the meantime, John has retained his commitment and I found standing for the ACCU Chair placed other demands on my time.
Anyway, having now given up the Chair I now have some time I can commit to Overload and have joined the team as a "Contributing Editor". John and I haven't discovered what that title means in practice yet, but we've decided it means that I can write editorials and John doesn't have to.
Six years on
Looking back to the editorial I wrote then makes me aware of quite how much Overload has changed during John's time as editor. While I think all the changes are for the better, it also raises the question of how it will change in the future.
One of the editorial concerns at that time was the range of material that Overload covered. When John took over, Overload was the journal of the ACCU's "C++ Special Interest Group" and was very much focussed on C++. When John took over he began expanding the range of material Overload published beyond C++ - and we regularly have articles on other languages and on other aspects of software development such as design and development methods. While this was good for Overload it did raise questions as to its relationship to the C++ SIG and, after a while, I (as C++ SIG organiser) severed the connection - allowing Overload to be repositioned as the ACCU journal for full members.
Despite having been dissociated from the C++ SIG the majority of Overload material continues to use C++. However, I feel the focus of such articles has changed: there is a tendency for them to be about designs, illustrated using C++, rather than about C++ itself. That is good, because C++ is an extremely expressive language, which continues to surprise and delight me (although I still have the concerns I expressed in Overload 7 about the demands it makes of developer skills).
The current C Vu editor (James Dennett) will recognise the situation John found himself in when he took on Overload: the previous editor had invested a lot of energy into the journal and had done everything (soliciting articles, reviewing them, and editing the journal) himself. John successfully introduced an innovation: he has built up a team of "readers" who work with the authors before publication by reviewing the articles (and making helpful suggestions). (One of the reasons I prefer writing for Overload to writing for C Vu is the feedback I get from the readers prior to publication.) The readers also help John decide what is suitable for publication. The value of having a team working on the journal proved itself when John had to take a break from editing and Einar Nilsen-Nygaard took over for a few issues with no break in the continuity.
Another change is perhaps the most obvious and also the easiest to overlook: the appearance of the journal. While the value of the journal is still in the material the improvements to the appearance from a professional production process are spectacular.
All of this makes Overload a much more impressive publication than it was six years ago.
The future
Over six years I've found that the work I'm doing has changed and that my interests have changed with it. Six years ago I was using C++ to create bits of software that worked without the author being present. Nowadays, I'm trying to create a software development process that works when I'm not there to keep things progressing. In both cases the biggest problem seems to be people that expect hard problems to have easy answers. I've also found that similar techniques are applicable: like using an informal "pattern language" to explain to managers why the fastest developer on a project might be a liability - and what to do about it. (But is this type of material of interest to Overload readers?)
Six years ago the lack of material led to two issues (17/18) being rolled into a single cover. The recent pleas for contributions indicate that this is still a risk. One thing that remains the same is the voluntary nature of the contributions and editing of the material. Those that do contribute are well aware of the benefits, but there has always been a need for new blood. If you feel like seeing your words in print then please get in touch - the Overload team is ready to help!
