Don't let the model slip away

This post is a little longer than my previous one but I hope you'll find it enlightening.

I'm going to start this article by stating a simple fact - Software Development is a multi-disciplined activity, covering scientific, engineering and artistic disciplines. Scientific because the design and construction of computers are based on sound scientific principles (physics, chemistry and mathematics), software is required at this level. Engineering because it takes scientific principles and solves real world problem (Engineering is the application of scientific knowledge to solving problems in the real world, from <http://whatisengineering.com/> - read the full quote on the site), software is required at this level. Artistic because this is the "the expression or application of human creative skill and imagination" according to a google search. I've seen this aspect of s/w development throughout my career, I've even been guilty of being more interested in this side of s/w development than the other areas. You all know this one, creating something that's of real world value but making it interesting and something that users would want to use.

Most disciplines if not all build models of some kind, to document their ideas, to capture the essence of the problem statement and to capture a representation of the potential solution. These models are used in many different ways. In some (bio-chemistry, micro-electronic/electrical engineering etc), ideas are researched, models are sketched out, with the intention that those models are not final, and through a process iterative refinement, the solution and model for that problem slowly emerge. In others (architecture, civil engineering), the requirements are captured, analysis is done (measurements, visual inspections of the sites, material analysis, and the list is extensive), and through a collaborative process engaging with the client, plans and models are constructed and iteratively refined, then the solution is constructed from those plans and model(s).

So what about software development, where are the models today and how are we working with them? I know models are being used in many software teams but most are seen as throw away artefacts, they act as a place where the team can gravitate around and discuss the problem as it is and where they think it should go. What is interesting is that most of the these models use a DIY notation, an unclear syntax that everyone agrees on at the time of use but someone new to the team wouldn't understand, with unclear semantics that everyone kind of understands at the time of use but because there's no standard, over time the semantics becomes muddled. 

So why has there been this growth in the DIY notation and a lack of adherence to the UML?

I've heard many say UML is too complex, too difficult to learn, takes too long to use, there's no point because the solution is captured in the code and tests. Let's examine each of these. Too complex - each UML model can be used with varying levels of accuracy, a bad tradesman blames his/her tool. Too difficult to learn - there a numerous sources available for learning the UML, it has a core model which links all the models together, once this is understood learning the UML models becomes easier. Takes too long to use - I always find this an interesting one, does using the UML really take any longer than that DIY notation that has no clear syntax or semantics? There's no point, the design is captured in the solution code and tests - this is the one I find the most dangerous. You have to remember that a solution is one persons or teams interpretation of a solution within the constraints of a typical piece of technology - namely the programming language. Good designs are language agnostic. It's also important to remember that a series of tests is not an indication of a design, they are simply tests indicating a series of inputs and expected outputs. You still need a design that should be language and platform agnostic, and can be challenged without having to trawl through thousands of lines of code.

What I always find interesting is that you don't hear electrical engineers, mechanical engineers, architects, biologist or chemists saying that the notation they use is too complex, they don't have time there's no point, etc, and even if they did complain about their disciplines notation they would still learn it and get on with using it. The UML is accurate, mathematically proven, can be used to capture problem statements and represent the solution without the need to examine a vast amount of code. 

In my next post I will give some insights into how the UML models all work together…