Title: Editorial

The only thing that is guaranteed in the programming world is change. We hope that it is progress, but that's more controversial. As the programming world changes, so we too change, updating our skills, specializing or diversifying as we choose, learning new things. Being the sum of its members, it is natural that ACCU also changes. It has grown and morphed significantly in the last few years, and will continue to do so.

The last two years have been something of a transitional period for ACCU: two major players have, at least partially, stepped aside in the last year or two to make way for new blood. Even so, ACCU still grew last year, and is well positioned to continue to grow. (As an aside: maybe we should not take it for granted that growth is a good thing, but it seems to me that it is an inescapable sideeffect of being good at what we do. If ACCU is valuable to existing members, it will be good for others and so will naturally tend to grow.) That growth will be fuelled by the actions of members, whether in filling existing roles or suggesting new paths to tread.

It has taken me since I took over the editorship of C Vu at the start of 2002 to feel that the handover period from the previous editor is really at an end. There have been glitches en route, certainly - thanks go to those who have politely pointed them out - but with help from the outgoing editor Francis and from our remarkably patient production editor Pippa none has been disastrous. The production editor's role, incidentally, covers just about everything about the journal except the contents of the articles. If you notice that C Vu (and Overload) look much more professional than the output of most user groups, it is the production editor to whom the credit should go.

Now that C Vu is through this transition, it is time to think about its future. There are many ideas on how C Vu can be made better - quicker/better review of articles, better suggestions for new articles, better use of the ACCU website to give information about the journal and to publish the source code that sometimes accompanies articles, and who knows what else. These and many others are good ideas, but I cannot do them all alone, and would not get the best results if I tried. I have recently had one offer of some assistance - would anyone else who has opinions on what they'd like from a future version of C Vu care to do something about it? If so, either get in touch with me (addresses on the contents page) or with Tom Hughes, the publications officer on your committee. Roles are flexible, and compensation is in the form of job satisfaction and maybe something to write on a CV (or resume if you're on this side of the pond). One note: please do not assume I'm addressing only some core group of familiar names within ACCU here. New blood is not only permitted but positively encouraged.

While ACCU's membership includes hobbyists and students as well as those who work in software development, the majority of those I know are professional software developers of one kind or another. Many of us work in software development companies. (Given the need to refer to everything in the industry by a TLA, these are often referred to as ISVs, for Independent Software Vendors.) Software companies' main asset is rather intangible: it's certainly not computer hardware, as that loses most of its value as soon as it is unpacked and usually most of the rest in the following 24 months, and there's no significant wealth in digital media or user guides. What is valuable is something else, something that is frequently labelled "Intellectual Property", and again this is abbreviated to IP, just to confuse matter in an industry where the acronym IP already had enough meanings.

For now, I'm going to make the (rash) assumption that this "IP" has value even if the creators leave the company. (One more diversion: companies who declare that their employees are their most valuable assets only just miss the point. Their people are free to leave at any time, give or take a notice period. The real asset a company can have is its ability to retain good employees.)

Some years ago, when I was learning martial arts, we had been working one evening on some techniques which lead to sitting astride one's opponent while he was on his back on the floor, with his arms pinned down by knees and legs and one's own arms and hands free to attack. (For the pacifists among you, imagine that I'm describing a particularly beautiful piece of origami. It might or might not help, but it won't do any harm.) Colin, our instructor, then announced that this position was an excellent one from which to start a fight - because you're going to win. I recommend the study of martial arts to any software developer: the combination of physical and mental exercise is an ideal way to leave the troubles of work behind.

It is not a good idea to use the term Intellectual Property without consideration. Advocates of draconian restrictions on how non-tangible goods can be used like to join many of them (copyrighted works, ideas protected by patent, trademarks) together and refer to them as property before the debate over how these goods should be used.

Possibly supporters of this position studied the same ideas Colin taught. If they can make enough people start the debate with the assumption that all intangible goods are property, you're likely to win: it's not going to be too hard to argue by analogy that they should be protected in similar ways to tangible goods. Lawmakers can rarely have the technical understanding to see that treating (say) software as if it were (say) house bricks makes no sense, but they do like to be able to apply existing bodies of law to new situations. Businesses whose interest is in claiming ownership of ideas can and do lobby effectively to get laws backing their position.

Much has been written on why the term IP is a disingenuous one, but yet complete refusal of programmers to cooperate is not an acceptable option within corporations that do rely on selling software to keep in business. The people running these businesses are usually comfortable with the idea of selling property to make a profit, and so it is uncomfortable for them to consider alternatives.

The job of a software developer divides into some coding/"pure" software stuff and judgment calls, some of them non-technical in nature. Many end up being ethical decisions:

At work, we're rarely just programmers. We have more or less desire/success to work purely on aspects of projects relating directly to software, but few can survive far into a career without having to spend considerable time doing things that are some way removed from the sharp end of writing code.

Companies are driven by money. There was a brief time, in the dotcom bubble days, when it seemed acceptable for companies to be driven by technology, but those days are gone (and mostly for the best). Those who control a company and its finances do not usually also have the time to be technical experts. That's why they employ us. Sometimes though the boundaries are blurred. A process to "capture Intellectual Property", for example, is likely to be motivated by financial/legal goals, and might well read like something that has been written more by lawyers than by anyone who understands software development. At least once in my career I looked at the existing defined process for capturing "IP" and knew that it could not reflect the reality of what happened in the organisation. Agile organisations and heavyweight protocols in the workplace don't mix. Process improvement works best, in my experience, in small increments - in fact, the ideas of agile methodologies apply just as well to software process and organisations as they do to the artefacts that we produce (code, documentation, test data etc.) On occasion it is necessary to have revolution rather than evolution, but when possible the quickest route between two points is often, seemingly paradoxically, found by taking the greatest possible number of small steps.

Each small step is easier to define and more likely to succeed than a drastic change, and success breeds success. Making some effort to document and communicate the creative works of a software development group is worthwhile for a number of reasons, however. It's something your organisation probably ought to do. If you get there first, with a lightweight process that still gives the business what it needs, you might avoid having a process mandated without such consideration for the realities of software development.

For all the criticism of C++ as suffering from a volatile evolution, the situation of many of us who use C++ compilers has improved significantly since the C++ Standard was officially ratified in 1998. Compilers released in the last year or two are generally fairly close to implementing the standard, and porting code between them has become significantly less burdensome. There were many glitches in the published C++ standard, some of which generated far more heated conversations than they warranted - such as the omission of a guarantee that std::vector<T> (for T other than bool) is contiguous so that it can be used to interface with code using raw (C-style) arrays. Five years on, an updated version of the C++ Standard has been published, including fixes for many errors that made it into the original 1998 document. The current C++ standard, as of April 1 2003, is ISO/IEC 14882:2003(E), replacing 14882:1998. The good news is that C++2003 does not introduce new features, and breaks little if any existing code. The other good news is that it will, for the first time, be published in book form later this year.

C last had a major facelift in 1999, and has also published one corrective update in the interim. While adoption of C99 (as the 1999 C standard is informally known) has been slow, it has beaten C++ to publication in book form. To quote Francis Glassborow: "The current C Standard (C99 + TC1 folded in) and the rationale is now available in book form published by Wiley (ISBN 0-470-84573-2). It is a hard cover lay flat binding with almost 800 pages. For once you might find it cheaper to buy in GBP (34.95) rather than US$ (65)." (TC1, for those who spend their time doing things other than learning minutae of the ISO standards process, is the first "technical corrigendum" to a standard - in more familiar terms, a service pack for a technical document.) Unlike a previous printing of the 1990 C Standard, which was accompanied by annotations considered by many to be a liability rather than an asset, these books just give the standards documents as they were meant to be read. These aren't books for beginner to intermediate level programmers to use when learning C++, but they are the ultimate references. For those who want something more portable than the $18 PDF versions, without spending the amazing sums the standards groups charge for a printed copy, this is good news.