Editorial

A Change of Job

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

Month One: Depression

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.

Month Two: Excitment

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.

XMI:

Rational Inc. and the Object Management Group (OMG) are working on a standard interchange format for modelling tools. XMI, the XML Metadata Interchange, is an XML encoding of a UML model. This has the potential to allow the seamless sharing of models between development tools. [ XMI ]

XML Schema:

The XML specification includes 'document type declarations' (DTDs) that provide a grammar for describing the contents of a class of document. Commerce One Inc. and Microsoft Inc. have developed more advanced schema languages, SOX and XDR respectively. The W3C accepted these as proposals for standardization, but elected to develop their own representation, named 'XML Schema'.

XML for UML:

Rational Inc. and Commerce One Inc. have developed a specification suggesting how UML may be used to design XML Schemas. [ UML-XML ]

OCL:

The Object Constraint Language is a component of the UML used for writing model constraints. It can be used for writing invariants on classes, and for specifying the pre and post conditions of operations. It has come out of the work of the formal methods community, so has a very strong formal mathematic background. I'm not aware of any mainstream modelling tools that support the use of OCL, but hopefully there will be support soon. [ OCL ]

MOF:

The Meta Object Facility is an OMG standard that describes the UML metamodel. A metamodel is a model of a model. In the case of UML it's a model of UML, and of course that model is itself written using UML. The OCL was in fact added to the UML specifically for writing the UML metamodel UML model. [ No the room is not spinning. At the first sitting this specification made me feel quite ill. We should leave the discussion of the meta-metamodel for another time. ]

CWM:

The Common Warehouse Metamodel is a specification for modelling metadata for relational, non-relational, multidimensional systems, and most other objects found in a data-warehousing environment. In addition, CWM models enable users to trace the lineage of data as CWM provides objects that describe where the data came from and when and how the data was created. Essentially, the CWM is a specification for a repository of UML models.

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.

Kevlin

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.

References

[ACM-Article] The Case for a New Business Model: Is software a product or a medium, Phillip G. Armour, Communications of the ACM, August 2000, Volume 43, Number 8.

[Conceptual-Modelling] Conceptual Modelling, Magnus Boman, et. al.

[GP] Generative Programming: Methods, Tools, and Applications. Krzysztof Czarnecki, Ulrich W. Eisenecker.

[OCL] UML - Object Constraint Language, Jos Warmer.

[Printers-Inc] Book shop and coffee bar, downtown Mountain View, California. See Overload 30, August 1999.

[UML-XML] UML for XML Schema Mapping Specification.

[XMI] XML Metadata Interchange, IBM.