"How much what is a good thing?" you may ask - the answer is "many things". In design it is often "how much abstraction is a good thing". In explaining it is often "how much simplification is a good thing?" In editing Overload it is "how much change is a good thing". Change is double edged: that which isn't prepared to change must be prepared to design, but inappropriate changes can lead to a quick death. The other problem with change is that it can catch the unwary. And, if you refer to my last editorial you will see that I was unaware of a change. (If you don't know what I'm talking about don't be concerned - I'm not being mysterious - all will be explained after a short digression into the role that Overload plays in ACCU.)
Sometimes queries arise as to why ACCU produces two publications - especially as it is sometimes unclear why material appears in one rather than the other. There are many answers, but, to me at least, the thing that distinguishes Overload from C Vu is that Overload covers design issues at a range of levels of interest. In comparison C Vu is much more focused on programming, and where design appears in C Vu it is mostly at the level of idioms. I'm happy with this division of scope, but in writing the last editorial had failed to realise quite how far away from its origins as a specialist C++ publication Overload has evolved. I wrote that I was unsure if a pattern language about team working would be appropriate. The editor and "readers" soon put me right about this! Of course, I'm happy about this - where else would I get such an article published? - but I do wonder if the readership is being left behind by the pace being set. I hope not, but unless some of you make your views known to us I can't be confident.
Whenever I meet up with ACCU members the conversation sooner or later turns to complaints about the way the industry operates. You know the sort of thing: why do managers make unreasonable demands? Why are (other) developers so incompetent? ... You have been there; you know how it goes. These issues are often raised as rhetorical questions; but, they are genuine problems and deserve answers; and, it is only by seeking answers that we can lay the groundwork for an effective solution. This type of issue should be appropriate to ACCU publications - after all it is clearly of interest to the members. And it was the view of the rest of the Overload team that it was appropriate for Overload to publish material that presents an analysis of these questions.
On the basis of my experience and beliefs I'm certain that in looking for solutions we should apply the lessons that we've learnt in our work. In particular, we know that some ways of communicating a solution are more effective than others. A particular lesson I draw from the "design patterns" movement is that it is helpful to include details of the motivating problem, the solution, and any trade-offs in the discussion of a "solution". However, when dealing with our less enlightened colleagues we often find orphaned solutions cut off from the original problems or rationale. And it is often these orphaned solutions that appear unreasonable. But is dismissing them as unreasonable a reasonable reaction? Is it just that we fail to recognise the motivating problem they successfully solve or is it that they are being used where they are not applicable?
One such "solution" that cropped up in discussion at a recent get-together of ACCU members in Nottingham - they know who they were - comes under the banner of "don't do as I do; do as I tell you". That is: a widespread tendency to make a statement about how things should be done and then to ignore it. A developer might tell you that maintainability is the most important concern in writing their code, but may be found trying the latest "cool trick" they have found in the language. Or an author may write, "error handling is important" and then omit mention of it throughout the book. Or a methodologist may say, "team building is important" and then only discuss the work processes and the work products.
We all know that these strategies can have undesirable consequences. The developer is unlikely to produce maintainable code from their experiment (although they may well learn something that can improve subsequent work). The author will fail to inform the reader how code should be written in a production environment (although they may successfully teach the principles). And the methodologist won't convey successful strategies for running a successful project (but may provide some useful milestones). But, instead of just complaining about the consequences, it is important to recognise that all of these behaviours reflect solutions to problems - and to consider what these problems might be.
It is easy to assume that these characters are idiots, but if we make the effort to think about what they are trying to achieve we see that there is a common thread running amongst them: "how much scope is a good thing". Without understanding the problem they face it is impossible to decide whether their approach improves the situation. The developer might need to master a new language feature in order to express the solution to a problem effectively. The author may need to simplify the subject matter to communicate the ideas or because of space constraints. The methodologist may be addressing the more serious problems. (Admittedly they might not - just don't jump to this conclusion.)
Whatever the case, if you don't take the time to understand why someone is acting the way they are then you will fail to engage them in a discussion of the merits of that behaviour. I have a lot of sympathy with the developer, author and methodologist (because I've done these things). I also have a lot of sympathy with confronting them (done that too). This editorial isn't really about solving these problems (and I don't have all the answers) but rather than leave them unresolved this is what I do in their positions:
-
As a developer experimenting with a new coding technique I try to leave it a while and to write it up before using it in production. (I'll be submitting an article about template metaprogramming for the next issue.) And if I can't explain it then I don't understand it well enough to use it. (So, if you don't see the article next time...) Occasionally I feel tempted to succumb to the "haven't got time for it" argument - but every time I do that I am reminded that "if you haven't got time to do it right then you haven't got time to do it wrong first and then fix it".
-
As an author I try to structure my code so that the error handling is as painless as possible and doesn't need to be omitted in articles. More often I'll omit whole functions or sections of code whose implementation is unsurprising. Sometimes I have to omit error handling during the initial presentation of ideas and then cover errors in a second pass. (And sometimes that second pass gets cut for space or time - to my subsequent regret.) But messy error handling usually indicates bad design: mine, or the API, or the programming language that I'm working with. (And that leads to another interesting discussion: how to work within the constraints of an imposed bad design.)
-
In talking about development methods I find that it is problematic to get ideas relating to team formation and environmental factors across. I don't yet know if this is a problem with me or the audience. (I have my suspicions - one senior manager dismissed my observation that improved morale on a project indicated that things were getting better with "they feel better because they think they can meet the new delivery dates, but that doesn't prove they will".) Seriously, though: it is my task to get the message through and I'm still working on it. (If you have ideas that can help, I, and a certain journal, will be interested.)
The moral of this editorial is to ensure that we understand the impact that our actions will have on others and the motives of others whose actions affect us. If only everyone in the industry would write code others will understand, would explain (and apply) techniques for handling error conditions, and would promote teamwork and improve (not denigrate) people's ways of working. If only everyone could be like us...
The team that produces Overload is dealing with a problem: the world is changing and we change with it. ACCU is changing - what was once a C specialist user group has now expanded its interests. Not only to other languages (C++, Java, Python, C#, etc.) but to software design, working practices and organisational issues. I think that most of us are programmers because we delight in novelty - I would certainly prefer to solve a new problem each day than to repeat a tired old solution endlessly. This is unusual in the population at large, but the ACCU members I speak to have that same attitude. Overload is changing - because the editorial team is solving the problems they think matter. These problems are reflected in the articles submitted and the experience of the team members. If you don't like our solution, try to understand why we are doing this - and if you have a better solution then we'll be glad of your help.
