"Nobody made a greater mistake than he who did nothing because he could do only a little." - Edmund Burke.
It is up to you to get involved
Once again I'm pleased with the response from authors - for the second issue running the advisors have been able to concentrate on providing assistance to the authors and to the editor and have not found it necessary to write articles to reach our minimum length. As you can see, we have comfortably achieved that again. Thanks to everyone who submitted an article! (I know some were redirected to C Vu, but the effort is appreciated.) I trust that those of you who have been thinking of writing will be inspired by this example and do so next time.
One of the benefits that ACCU can provide is the opportunity to learn new skills safely outside the work environment. I know that I have learnt a lot from my ACCU activities - as an author, as the chair, as a speaker and now as a journal editor. When people occupy a position for an extended period there are pros and cons: they provide us all the benefit of their experience, but they also block others from that same learning experience.
If you check your back issues you'll see that some of the advisors have been working on Overload longer than I've been editor - a long time. We've all benefited from their diligence and expertise over the years. Thanks team!
For a couple of reasons now is a good time for new people to get involved in producing this magazine. The first reason is to bring new skills to the task: over the last couple of issues I've had to ask for help from outside the team to review articles that require more knowledge of CSS, C# and neural networks than the current advisors have. (I'm always willing to do this, but CSS and C# are hardly obscure.) A second reason is that recently several of the current advisors have taken on new commitments in their lives. (Some of these commitments have to do with ACCU, some are personal, but all have the effect that the editorial team has reduced capacity and would welcome some new blood.)
If you have a clear idea of what makes a good article about software development and would like to help authors polish their writing then now is the time to get involved - while the old hands are here to "show the ropes" (and before some of them find their new commitments push contributing to Overload every issue out of their lives). It isn't hard - and the authors do appreciate the work done reviewing their articles.
The quest for usability
For many years I've puzzled to understand why, when people try to make a piece of software they are working on more useful (or "reusable") they take actions that have the opposite effect. I may have previously described how a simple "properties" class I wrote to hold configuration information was "improved" by another developer who needed to serialize it: by including the serialisation code he needed in the class he made it less useful in contexts which don't need the same approach to serialisation - I'm sure you can add many examples from your own experience.
What people repeatedly miss is that simple things that do one clearly defined thing are more usable than complex ones that do a host of things. There is even a clear tendency for people to add functionality "because we will need it later" - this is recognised in the Agile mantra "you aren't gonna need it" [ YAGNI ]. I've seen projects drowning in code that contributes nothing at the moment but was written and is being kept "because we will need it later". Not only are these projects typically over budget already, but they are also continuing to lose time because of the cost of compiling, changing and testing this useless code. My experience isn't unique - Tim Penhey wrote recently about a project that had recognised this condition and was investing a substantial effort to identify and remove dead code [ Penhey ].
The code that causes development problems may not always be completely useless - with a diverse or large user community there is often someone, somewhere, who uses it. If there are enough units sold then providing value to even a small proportion of users may justify the expense. The problem I've seen in this scenario is that there is no objective basis to make this decision: it is hard to quantify the cost of slowing down all changes to a system - not only is it difficult to quantify the lost productivity, but when new features are delivered slowly there can be significant opportunity costs (and these may be hidden - the benefits of possible features may not even be evaluated "because of the backlog").
Operating systems often meet the criteria of large, diverse user communities and it is no wonder that they have a history of developing lumps of near dead code that are needed for "backward compatibility" and have to be worked around for new development. I can remember IBM boasting proudly of how complex they had made MVS+S/390 - and, for many years, the press releases and briefings about forthcoming versions Windows have shown all the signs of optimism obscuring the difficulty of developing a codebase with so much baggage. Of course, "difficult" isn't "impossible" - we as a profession keep pushing back the boundaries of what is possible. S/390, WinNT, Win2K and WinXP were all delivered eventually - but without some of the functionality mooted in early "roadmaps".
It is, of course, easier in most projects to remove functionality that exists only in the plan than to remove functionality that has been developed in the code. In the latter case, more has been invested in creating that functionality - and there is also the risk that someone, somewhere is using it (or will want to use it someday). Hence the common experience that, in practice, as the codebase grows it accumulates increasing amounts of dead code that sucks vitality from the project.
Not just software
However, as I don't want to drift too far off topic, I'll get back on track with some comments about J2EE. Time was that J2EE was the new simple way to deliver a whole range of server-side applications. I remember those days - I worked on some systems in this category. As with many development tools, if what you wanted fitted the design parameters then it was great! (And if it didn't you either had to code around it or used different tools - I've worked on projects that took both approaches.) Over the years J2EE has accumulated new libraries, new technologies and grown in complexity until it gets comments like "In five years, Java EE will be the CORBA of the 21 st Century. People will look at it and say, 'It had its time but nobody uses it any more because it was too complicated.'" Richard Monson-Haefel (Senior Analyst, Burton Group) - reported on The Register by Gavin Clarke [ Clarke ].
It isn't just software projects that that suffer from accumulating well motivated, but counter-productive, complexity. There is scarcely a day that goes by without something of this nature appearing in the news. Today's example was the UK's ID card scheme - a project filled with stuff that "might be useful" to the extent that it is far from clear that it addresses the anti-terrorism problem it purports to address.
I've not worked on a Java project for some time now, so I can't attest to the accuracy of these comments - but I heard very similar remarks about JDK5 at the ACCU conference a couple of years ago and noticed how rapidly the proportion of Java content had reduced at the last one. I'm sure Java will be around for a good while yet - but the complexity it has accumulated isn't helping.
I can imaging the C++ developers amongst you smiling at this and feeling smug that you avoided the Java "fad". Don't be! It is a lot like the decaying codebases I was describing earlier - much of the complexity in C++ is there because the standards committee doesn't dare to remove it. There are features that "might be useful" (while I've heard reports from people who are using custom allocators, these uses don't justify the cost to everyone else of maintaining them in the standard). There are features that someone started to work on, but didn't have time to finish ( valarray does have users and there are some ongoing efforts to resolve the issues). There are even features that never seem quite right and were being reworked right up to the moment of shipping (like auto_ptr ).
In another world
It doesn't have to be that way. While working on a codebase it is possible to delete the dead code and amputate the dying features. I know - I've done it - and the results are worth it. One of my more memorable days was when I deleted around 800 lines of code from a function and could then see that a condition had been coded incorrectly. (The deleted code had accumulated bit by bit to identify and fix up various specific scenarios that had been reported as being wrong. I deleted it bit by bit on the basis that "this shouldn't be doing anything".) Of course, it is prudent to have both version control and a good test suite in place before getting too eager with the "hatchet".
One of the keynotes at the last conference dealt with changes being made to the Python language. I know that many of us feel this was not a good topic for a plenary session, but it did give an insight into a very different strategy for maintaining a language. Changes are being made that break "backward compatibility"- something that Java and C++ go to tremendous lengths to avoid. Instead there were tools being considered that would help with the identification and migration of code that relied on the features obsoleted.
There are differences between the communities that Python and C++ support. But considerations such as "don't break backward compatibility" are not absolute requirements for Java and C++. C++ in particular supports a far wider range of environments.
Can you do anything?
You may feel that you can't do much about Overload, your codebase or the language standard. You are wrong: if you already find the time to read an article in Overload when it arrives then it doesn't take long to write some review comments; if you are developing some class it won't take any time to not add that bell or whistle; and. if you are looking at some code that isn't being used it doesn't take long to select and delete.
Progress is made one step at a time.
References
[ YAGNI ] "you aren't gonna need it" http://c2.com/cgi/wiki?YouArentGonnaNeedIt
[ Penhey ] "Dead Code", Tim Penhey, Overload 71
[ Clarke ] "JEE5: the beginning of the end?", Gavin Clarke, The Register http://www.regdeveloper.co.uk/2006/07/12/java_ee_burton_group/
