Editorial

I have recently, once again, changed employers. The first month was depressing, the second was exciting. This column charts my journey between these tropics.

The company I have joined is both small and young; one hundred people and one year old. They have a rather dull business problem to solve; from which they hope to reap buckets of money. But while problem may be mundane, the ultimate solution is not.

They have succeeded in a small way by following the usual software development methodology: Analyse the business knowledge, map it into a model, and implement the code. Well, to be honest, they skipped the first and second bits and just wrote the code, but that's only where the trouble begins. As each new requirement of the system arrives we iterate through the whole process again. This is what you'd expect for major software releases with a year between revisions, but in our case the deployment of each and every customer introduces new requirements into the system, which we hope to be a weekly event. The implemented solution meets neither the scalability nor flexability requirements of the business.

This failure stems from the short sightedness of the original system designers in not focusing on the fundamentals and on their reliance upon 'tools'.

One component of the extreme methodology that I disagree with is 'build for today, not for tomorrow'. The majority of my work has been on large server systems that had to be built today for tomorrow and serve as a platform for the future. In some cases designing functionality two versions ahead, and three years into the future. To me architectural vision is of key importance in any software project.

My approach to software engineering has always been from first principles. Step 1: Identify and document the problem. This is often hard, as the people closest to the problem tend to only know a small piece if it well. This is reminiscent of the five blindfolded men asked to identify an object in a room. One man believes it is a snake, another believes it to be a tree. I forget what the other three were up to, but the thing is actually an elephant. Step 2: Devise a solution from first principles. Ignore implementation; just solve the problem. Step 3: Search for appropriate off the shelf systems, components, tools and technologies that could form an implementation. Step 4: Buy what can be bought, and build what can't. Step 5: Integrate.

I have rarely come across so many people able only to think in terms of tools and technologies. Given a problem they'll cast about for any vaguely relevant tool hoping it'll serve as a solution. They'll then combine it with some other randomly selected component. If that doesn't work out they'll blame the tool, and decide that the next version of the tool will actually solve the problem. Or, that some other brand of tool within the same category of tools is in fact a better solution. Never questioning whether the category of tool is even appropriate. Actually studying the problem from a fundamental viewpoint and developing a language and model of the problem domain seem to be alien concepts to these engineers. [Conceptual-Modelling]

My Depression: The body of a startup company is a host for dysfunctional behaviour.

Having determined the sanity bisector, I settled down to think about the problem from scratch.

The fundamental problem is that the soft code of the system has been hard coded. The system needs to be able to adjust itself dynamically to a changing environment at runtime. Czarnecki and Eisenecker describe this type of system as being adaptive in their superb book 'Generative Programming'. [GP]

Having identified the real problem, I set about to document the problem, and to define the requirements of a solution. I then cast about in the software engineering literature for examples of similar problems and solutions. For this kind of exploration I find the digital libraries of the ACM and the IEEE to be invaluable.

Unfortunately I can't say too much about the details of the problem or solution, as the lawyer guy in the office next door will have a fit. I can however discuss the topics I've been investigating recently, which I hope might be of interest to some of you.

Until this month all of these efforts were totally unknown to me. It's easy to get yourself into the comfortable position of thinking that you've pretty much seen a bit of everything in software engineering. My team leader gave me some advice during an exit interview some years ago. 'You're bright, but never stop learning. If you get comfortable, you're doomed.'

If you're feeling comfortable, then you're probably not an Overload subscriber. But, if your mind is parked in front of the television with a beer in one fist and the remote in the other: then I highly recommend 'Generative Programming'. It opens up a whole new horizon of thought.

My excitement: I am no longer a mere-programmer. I am a meta-programmer.

I picked up a copy of Java Report the other day in Printers Inc., ordered a coffee, flicked through the magazine, and there was Kevlin Henney staring out of page 92. It made me feel so proud: our Kevlin, international superstar of the object world! [Printers-Inc]

Over the years Kevlin has made a huge contribution to Overload, and I hope his work between these covers has contributed to his success.

The subtext of these paragraphs is that each of you should stop for a moment and think about your contribution to Overload, and what Overload could do for you. Without Kevlin stepping in at the last moment with an article previously printed in C++ Report this issue would not have been completed.

Each of us has a worthy software tale to tell, perhaps not with the eloquence of Mr. Henny, but the editorial board are experienced at helping authors polish up their texts for publication.

Software is just another medium for knowledge. [ACM-Article] If you're a programmer, then you're a writer.