Models as Dictionaries

Posted by Keith McMillan

March 6, 2008 | Leave a Comment

Daniel and I got to talking again today about our favorite topic of late: what good are models in an agile environment? We reached some interesting conclusions.

We think that the process of developing a software system is in some ways inventing a new language. All the stakeholders, that is to say the developers, customers, and other interested parties, have to agree on their nouns and verbs, their common terms, which are the business concepts manipulated by the system. As we begin to identify a subset of those foundational concepts, we can they begin to form higher level constructs, such as sentences, descriptions of how the system behaves and manipulates those basic constructs. As these activities take place, the language is refined and expanded, new words are added to the vocabulary and new sentences are created, and it becomes easier and quicker to find ways to explain concepts and form yet more new sentences. This parallels nicely the way that real teams develop real systems, right down to the acceleration and growing shared understanding of the problem.

Now here’s where the modeling comes in. Just as with a natural language, we can make up our words in a meeting, and write them down on a white board, and erase them when we walk from the room, and that’s perfectly fine. We should realize that if we do that, we forgo the ability to let others learn the language as well, except from us. Further we are now required to remember the definition of every word and the nuances of every sentence. Most of us are pretty good at remembering words, but we still have dictionaries to help us out, so it’s a pretty good bet that a documented model would be useful as well.

Here’s where things start to get interesting. Companies themselves can also be modeled as systems, as can software development efforts. Development processes are also dictionaries of techniques for building software. To quote Daniel, who’s put it more succinctly than I could:

We can use the RUP (or another sufficiently-structured tome) as a dictionary to have a common language we can use to talk about how our processes are going (or not). Without that common language, it’s very hard for the team to communicate — it’s very hard for the organization to communicate to the team. It’s hard to have a discussion around what is working and what is not working. The RUP, in this case, is the common language that the industry has agreed upon that we can use to apply to create processes to solve our problems, just like we use the intermediate language with our customer to describe the problems that we can then apply solutions for. Just like the idea that we shouldn’t have a problem that our user brings us that we don’t have language for, we shouldn’t have problems with process in our software teams that we don’t have a way of describing. Not being able to describe problems in a common language prevents solutions from forming. I guess you could call it “Process Architecture”

When you think of a software development as a language, some other analogies jump out at you. Just as you wouldn’t try to write a novel using every possible word, you don’t want to use every tool and technique mentioned by every process for every project. You need to pick and choose the words and phrases (or tools and techniques) that are the correct ones to get your points across.

It’s a fairly robust analogy, I believe. I think chewing on this for a while may yield further insights for us.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.