Mark’s editorial “An Industry That Refuses To Learn” (Overload 60) clearly struck a chord of recognition – as you can see from the letters page. It is disappointing, however, that no-one makes the case for there being improvements in the industry. Despite the depressing repetition of mistakes and rediscovery of ideas, some things have changed for the better!
One of the things that has changed is the ease with which ideas, techniques and even tools circulate. And this isn’t just the advent of new technologies – when I started in the industry the only books around the office tended to be manuals for the system being used. Now I can look around the office to find copies of DeMarco’s “Peopleware”, Senge’s “Fifth Discipline”, Cockburn’s “Effective Use Cases” and “Agile Software Development”, along with a miscellany of books on Design Patterns and Extreme Programming. Some of the ideas these contain are even being put into practice! It may be taking time, but change is happening. And Overload has a role to play in ensuring that useful knowledge is not forgotten.
Of course, the trouble with change is ensuring that we keep the good and discard the bad. And that is particularly on my mind at the moment. The more observant of you may have noticed a change to Overload (but I hope that there is nothing that has caused you to notice). Let me explain.
At the AGM Tom Hughes stood down from the post of Publications Officer having successfully steered the journals through a number of changes in the last few years. This gave the previous Overload editor, John Merrells, the opportunity to join the committee as the new Publications Officer (which might be considered a promotion). That left a gap to be filled as Overload editor – and, when it was offered to me, I took it on. I hope that you will all join me in thanking Tom and John for their efforts over the years, and to wish John success in his new role.
It was only a year ago that I joined the Overload team as a “contributing editor” – and took on the some of the editorial tasks, such as producing the editorial. These are tasks that I’ve subsequently shared with Overload’s remaining contributing editor, Mark Radford. The first of these editorials reviewed the changes that had happened to Overload since John took it over (from me) and concluded: “All of this makes Overload a much more impressive publication than it was six years ago.”
The last year has not changed that opinion: I’m very happy with the way that Overload has developed under John Merrells’ guidance. I hope that you are too. It should therefore be no surprise that I’ve not taken on the editorial role with any dynamic agenda for change. Most of the Overload team remains in place and will be performing the same role: helping authors to prepare their work for publication. And with any luck you, the readers, will continue to find interesting things happening to write articles about.
Having said that, I must immediately confess that some changes are intended: John Merrells, Paul Johnson (the new C Vu editor) and I have agreed that the distinction between the journals has not been clear to the readership. In part this has been due to a failure to route articles to the other journal when that was appropriate. In the future we intend to ensure that articles are re-routed if appropriate. I trust that this won’t upset anyone.
Which all begs the question “in which journal does an article belong?” While those working on the journals tend to agree on each specific article that has been discussed, it isn’t that easy to explain. Especially as some members (and the ACCU website) appear to have views that differ markedly from ours. So let me go on record about a couple of things:
Overload is no longer a C++ based publication: it covers a much broader range of material – the current issue discusses team working; design patterns; the use of exceptions in C#, Java and C++; and the high competency threshold set by C++.
Overload is not a minority interest: the vast majority of ACCU members (just over 85%) subscribe to Overload.
So what is Overload about? In the editorial mentioned above I said of Overload articles that “there is a tendency for them to be about designs, illustrated using C++, rather than about C++ itself”. Having thought about it over the past year I no longer think that captures it at all: The articles assume that most basic development skills have been mastered and address problems faced by journeyman (or master) developers. (While the industry does not have a recognised apprenticeship system it does have recognised masters.) These articles might examine the effect of applying alternative solutions; or discuss new tools and ideas; or show old ideas in a new light. There are reports back from those venturing away from the mainstream approaches in the hopes of finding something better. And don’t forget that what is “mainstream” for one technology may be new ground for another – we need to exchange ideas.
And the exchange of ideas was the theme of a “Birds of a Feather” [BOF] session on C++ that I led at the conference. (Why C++? – because I’m currently working in that language and missing the support that is available for working in Java.) In that BOF I led a discussion of tools and techniques that people had enjoyed in other languages that they lacked when working in C++. Many things came to light from developers using Java:
Using a refactoring IDE (Eclipse, IntelliJ) changes the way that you think about maintaining and developing code (and makes things achievable that were not before).
Having a de-facto standard for a unit test framework (JUnit) makes test driven development that much easier to establish.
Tools for automating integration, build and smoke test processes (CruiseControl, AntHill) make frequent (or continuous) builds easy to put in place – not a continuous battle.
I’m sure there are others, but these types of tool have a long history in the SmallTalk community – and only became commonplace when ex-SmallTalkers reimplemented them after moving to Java.
The BOF wasn’t entirely a matter of discussing the greener grass and sighing with regret: an interesting discussion of various unit testing frameworks developed with people relating why they’d written their own (about half the room had done this). People expressed various dissatisfactions with CppUnit , CricketTest , CppUnitLight , and CxxUnit , but, interestingly, boost::test got no bad reports. There were not enough reports on boost::test to announce it a winner, but people were sufficiently interested to say they’d go away and try it. (I’ve not had any reports back yet – but I’ll keep you informed.)
Another thing that was discussed was whether there were technical obstacles to the development of C++ refactoring tools. It was felt that the difficulty of compiling C++ and the way that a piece of code can appear in multiple translation units made this a lot harder than equivalent tools for SmallTalk or Java. But it was thought possible.
Developers, it seems, are not the only ones to recognise the potential for refactoring tools for C++. After I mentioned refactoring tools for C++ in my “Christmas List” (Overload 58), Giovanni Asproni emailed me with links to an alpha version of a C++ refactoring tool: http://www.xref-tech.com/ and to SlickEdit: http://www.slickedit.com/ which advertises these features. Microsoft has also listed “refactoring” as a feature of their forthcoming IDE. I’ve not, as yet, had time to review any of these offerings, so the reality may be less than the promise, but I am looking forward with anticipation.
Of course, it isn’t just within the C++ arena that things are happening. I’ve been hearing from developers taking a first look at Java’s JDK 1.5, which it seems has grown a host of new features. But while I’ve heard a few rumours I can’t yet provide an informed report of any interesting developments there.
I’d love to be able to report on progress in other areas:
Languages like Python and C# are widely used by ACCU members. (But not, at the moment, by me).
New development tools have become available and some of them change the way we can think about developing software. (I’ve mentioned some of these above.)
Ideas and techniques for handling various elements of the development process are being explored. (I know of one developer who took the suggestion that “test driven development wouldn’t be appropriate to a compiler” as a challenge, and has used that approach to write a compiler.)
Anything else that develops the art/craft/science of software development.
I want to know more, and my guess is that many of you do too. I also know that my time is limited and have no reason to believe that yours is any different. But if you are reading this and thinking “doesn’t he know about X” then you can help the rest of us by submitting an article. (It is only fair, you discovered about A, F and M through articles in Overload.)
C++ wasn’t the only thing I talked about at the Spring Conference – I ran a second BOF in conjunction with Neil Martin that discussed the possible role that ACCU could play in promoting a professional approach to software development. Lots of ideas were discussed, including certification schemes. Neil went away to investigate what the implications of becoming a certifying body were, and I got a mailing list set up that includes the people that expressed an interest. While Neil has reported back to the list nothing else has happened (yet). Perhaps someone reading this can provide the necessary impetus.
I hope that I’m going to enjoy editing Overload, I have certainly discovered that it involves work. I’m writing the first draft of this editorial on the train home from working at a client’s for the last few days – and it has to go to the production editor tonight! (So no chance to mull it over for a few days.) But, so long as worthwhile articles are submitted, I feel that the effort is worthwhile.
Things are changing: new people, new ideas, some things don’t – some problems are there just because there are people involved. But let me repeat a suggestion made to me at the Extreme Tuesday Club (sorry, I’ve forgotten your name, but I owe you a pint) of something that isn’t just an old idea reinvented: aspect oriented programming. What do you think? Seen it before?
While Mark had a valid point that some good old things have been forgotten, there are sometimes new things under the sun, and these may be good too.