Imprecise Models and Killing Hippies

You'll gather by now from the torrent of posts (well, a relative torrent for me) that I'm catching up on my blogging. We've been pretty heads down of late getting our latest CTP out of the door. Bear with me, this is a long one.

 

A while back, Harry had a post that was even more interesting than his usual high standard. Entitled "Code is Model" is set out something of a manifesto (or a set of tenets as its fashionable to call them) for making models more relevant to the software construction process and more acceptable to the industry as more than "pretty pictures".

 

Number one on this list was the following

 

  • Models must be Precise
    There must be no ambiguity in the meaning of the elements in a model. In C#, every statement and keyword has an exact well-defined meaning. There is never a question as to what any given piece of C# code means. There may be context-sensitive meanings, such as how the keyword "using" has different meanings in C# depending on where it is used. If you don't have a similar level of precision in your model, there's no way to transform it to lower abstraction models in a deterministic fashion. Models that can't be transformed into lower abstraction models are nothing more than pretty pictures - perhaps useful for communication with other people on the project, but useless as development artefacts.

 

Now as a fully-paid-up member of the DSL Tools team, you'd expect me to be waving pom-poms here, but in fact this tenet put me in mind of the first track on the excellent Primal Scream album "XTRMNTR", called "Kill All Hippies". When I first bought this album, the track name raised a wry smile with me - as a young fellow, I was inclined to get irritated to the point of apoplexy with the vagueness and well meaning-but-don't-actually-get-anything-done attitudes I perceived to come from hippies and I'd have been vehemently in agreement with the Primals' sentiment - in an entirely non-aggressive way of course ;-).

 

I've mellowed a bit since then, (some may disagree) and I find that a bit of refusal to tie things down too early can be a useful counterpoint to my own tendency to make every decision as fast as possible and be rather unbending about changing them from then on.

 

So although as an industry we desperately need to drag models kicking and screaming from the far left of pretty-picturedom a good long way to the right in the direction of precision, I don't want to throw the baby out with the bathwater.

 

I'm going to take it as a given that folks believe that precise models are valuable development artefacts. Why do I think imprecise models are also valuable? Here are three things that tools for imprecise models help you to do:

 

  1. Communicate with people about design
  2. Think out loud in a way that's more shareable that your whiteboard
  3. Start with an imprecise model and progress gradually toward precise models

 

Hopefully the first of these is obvious - there is value in model as communication device - it's just not enormous.  I've talked before about the value of the second - I draw pictures on my whiteboard and when I'm on a conference call to Redmond, they're effectively useless.

 

The third is something I've only recently become a convert to.  I'm happy to have models which are not precise so long as I can still reason about them programmatically.  This allows me to have development processes that are about a quantitive process of iterative refinement.

 

Here's an example - in some infrastructure modelling tool, I have a node type which specifies a logical machine group.  One of its properties is the number of actual machines required to suit the proposed scale of the application to be deployed.  I'd like to be able to put "Depends on outcome of Fred's scalability investigation" into that numeric field, or perhaps "4->8".  I can still generate a pretty good report from this model, but I can't really provision a set of physical servers from it.

 

But here's the kicker - it's vital that I can write tools that programmatically assess this model and tell me what work needs to be done in order to make it precise.  I want to know exactly what must be done on this model before, for example, it is suitable for feeding into some kind of provisioning tool.  You might say it needs to be precisely imprecise; I prefer to think of it as quantifiable imprecision.

 

What this all comes down to is awareness.  I wasn't good with hippies until I was self-aware enough to value their difference from me.  Even imprecise models need to be precisely programmable if we're to be aware what uses they can be put to.

 

Edited: Forgot to link to Harry's original article.