Naked Objects

I consider myself to be something of an expert on Lego.  In 1984 I wrote a book about robotics, which included instructions for building a number of quite sophisticated robots using Lego Technic.  The book never sold well, and is now long out of print  -  but it did make my (substantial) Lego purchases tax deductable!  Lego has oft been used as a metaphor for componentised software.  I think it’s a poor metaphor, except insofar as it exposes the woolly thinking that surrounds the idea of software componentisation generally.  A componentised system is one in which it is possible to replace a component with another implementation that conforms to the same specification:  thereby not only giving you the choice of alternative suppliers, but also to encourage innovation.  Sound and video systems, desktop PCs, and bicycles are examples of strongly componentised architectures.  Software is increasingly componentised thanks to the growth of strongly defined interfaces, from public standards to Spring beans. (Note: although objects and services can perform the role of components, generally they do not:  objects, components and services are in fact three complementary but quite distinct ideas  -  the subject for a future blog.) Lego is not a componentised architecture.  With the exception of different-coloured bricks there are few opportunities to swap one Lego piece for another that confirms to the same spec but that offers certain advantages.  There are even less opportunity to swap a Lego piece for one from a different manufacturer.  (Trivia:  the most patented part of a Lego brick is not the knobs on the top, but the underside of the brick).   

One could possibly hold up Lego as a metaphor for a rich plug-in architecture such as Eclipse, where new ‘pieces’ can be plugged into almost any point on the existing system due to a single comprehensive joining mechanism.  But there are few examples of such well defined plug-in software architectures, and the metaphor doesn’t really enrich our understanding of them. However, I want to argue that Lego is a very good metaphor for another emerging trend in software development: the Domain Specific Language or DSL.  Lego, in common with music, crochet, and predicate calculus, is fundamentally a domain specific language. The domain is building small-scale (usually!) physical models, both visual and functional.   Within any given domain one can easily envision multiple languages, each with its advantages and disadvantages.  The book that I mentioned above, in fact had projects both for Lego Technic and for Fischertechnik, a German construction set, and leafing through it again for the first time in many years I see that I devoted a couple of pages to comparing the two for the specific application of building robots.  A useful way to compare two domain-specific languages is along two dimensions.  One dimension is applicability:  the range of different things that can be expressed in the language (within the domain boundaries that is).  The second is the parsimony of the language: which translates readily into productivity.   What prompted me to write this week’s blog was a conversation with Philip O’Donohoe at the DSFA in Ireland.   Philip reminded me that back in 1999 when I first started working with them, I had the whole of the management team playing with Lego in a workshop.  One of the assignments was to take a collection of varied Lego pieces and to lay them out on a large 2×2 grid representing the two axes described above.  The photo below shows one such example:  The horizontal axis is the breadth of applicability; the vertical axis is the parsimony or productivity gain.   So, bottom right you have the basic building blocks of Lego such as bricks, beams and plates; top left you have pieces that add a lot of value if you are building one very specific type of model, but that lack generality.  Bottom left you have the equivalent of what programmers call ‘cruft’  -   small pieces that have low applicability and low value-add.  The most valuable pieces, and the hardest to conceive and design are in the top right.  Over the last five years the DSFA has created its own ‘Common BOM’ (Business Object Model).  To use the most up to date parlence, their Common BOM is really a Domain Specific Language, and it is as good an example of a DSL as you will find anywhere in the world.  What makes it a good DSL, I believe, is that it is defined as a very pure object model.  Objects are not the only way to define a DSL, but I believe, passionately, that they are the best way  -  or at least the best way that is available to us as a practical proposition right now. The Common BOM has already proven its worth: perhaps the most striking example being when the 50,000 lines of code in the prior Child Benefit Administration system were replaced by a new system based on the Common BOM plus less than 1000 lines of bespoke application code.  The DSFA is not content to leave it there:  over the next four years they want to further improve it: to broaden its applicability (i.e. to support an even bigger set of business applications); and to make it more powerful (i.e. reduce the number of steps needed to create an application). To that end Philip was saying to me that they now want to go back and ‘do the Lego 2×2’ exercise on the Common BOM.  Lego is not in fact one DSL, but several.  It started as a DSL for building model houses; then in 1961 came the first wheel and the capability to model vehicles, followed by trains in the mid ‘60s; now there are Lego DSLs for pirates, space travel, and many more.  Each of these DSLs is defined by a set of pieces.  What makes all of them so effective, though, is the generic coupling mechanism (the famous Lego knobs) that makes it easy to use the language. The DSFA’s Common BOM is not dependent upon Naked Objects – having now been designed it could be deployed within a more conventional architecture  -  but the value that Naked Objects adds to the Common BOM is that it makes it  easy to use as a DSL.  The elements of the language (the objects themselves) are easy to get hold of and manipulate; turning them into a prototype does not involve gluing them together with user interface code; and the results are quite presentable, so that everyone can still clearly see the elements of the DSL in the finished product. 

I can’t wait to see the results of the DSFA’s 2×2 assessment. I’m off up to the attic now to drag the Lego set out again . . .

Richard Pawson