I was flipping through Fowler’s Analysis Patterns tonight. He uses the term “Conceptual Modeler” – I like that term. I think it is a very accurate term that describes a key element in software development : conceptually modeling the domain in the software. He also had a quote in the intro of the book that was something like

 

“Much of my skill comes from a knowledge of modeling techniques and how to use them”.

 

I also agree here. I think that much of the value I add to projects comes in the conceptual modeling. This is a notion that I think is often overlooked and more often under appreciated in software development. While I find myself being ‘anal’ as can be as a coder – and demanding the same of my teams – I believe that the modeling part is much more important than just the ‘raw coding’ part.

 

In maybe my all time favorite software book – Domain Driven Design, Evans talks about “conceptual contours”, “digging out concepts”, “supple design”, “making implicit concepts explicit” and “a model expressed in software”. These all echo the same sentiment that Fowler is indicating. In the end – there is an underlying set of real world concepts that we are trying to model in the software. Our task is to make the most useful software model of the real world domains that we are dealing with. We work with domain experts to elicit the real underlying ideas and concepts from them so that we can structure our software in a way that mirrors the real domain.

I often think that what I typically call “Modeling Sessions” are just about the most productive times that I have with my groups. Modeling Sessions are usually impromptu times when I grab 1 or more developers and try to model out some ideas. Since I generally do not believe in BDUF – so these modeling sessions are NOT a week long endeavor. Having a close knit team with extremely high levels of communication enables frequent, relatively brief modeling session.

Basically – we white board, draw on scrap paper and talk around the domain we are trying to model. We do our best to extract the most useful yet simplest model for the domain we are dealing with. Sometimes we have ‘impassioned’ debate (usually between 2 or more senior level developers that have modeled the item in debate differently in the past). In general these sessions have 1 goal – define a set of abstractions for this specific ‘item’. Often we have ‘class notes’ as an output of these meetings – some drawn out interfaces (used to describe behaviors) and perhaps some more ‘entity object’ type structures that model heiricacaldata and/ or database data. “Design patterns”, the classic ones, and the repeated patterns within our applications come up again and again in these meetings. You could hear us say things like:

1. “Usually you would use a strategy pattern for this type of situation” or

2. “In order to be consistent within the application, we did this thing in place X and this notion is similar – should we do it that way here?” or

3. “That thing you keep mentioning – the ‘…’ was it? It is not in the software really – lets make it absolutely explicit” or

4. “Wow – if we introduce this idea, then ‘…’ and ‘…..’ will become significantly more clear and easy to work with – it just makes total sense.”

Modeling sessions also enable more jr developers and/ or new team members to learn a great deal. I believe these sessions can accelerate the learning by ‘amplifying’ the knowledge in a context that is relevant. When people are learning abstract software development patterns and paradigms, out of context they can seem academic and useless. When people are seeing software modeling in practical context – relevant to their work, the ideas become clear, the patterns seem full of utility and fulfil their purpose.

In these sessions, patterns provide a great meta-language. The ‘classical patterns’ and the patterns that are part of the domain model your team has developed become the meta-language of these modelling sessions. You do not really have to say “We can just make a class – who’s only job it is – is to create concrete classes that are derived from this abstract base class”. In stead – you just say we need a ‘factory’. This is also something that Evans talks about in Domain Driven Design – he calls it the “Ubiquitous Language”. When the team is comminicating frequently and effectivley – using a meta-language of ‘normal patterns’ and patterns that are specific to your teams domain model – much more can be accomplished.

Anyhow – modeling sessions – take your team, work with them. Do architecture as a group – this is often a series of ‘modeling sessions’. Software developers really should be 1st class ‘conceptual modelers’ not just ‘coders’.

 

-Chris

Comment on this post below

You must be logged in to post a comment.

You can leave a response, or trackback from your own site.