On Choosing Proper Models

When software developers talk about a project, concept, or just about anything else, we normally speak in reference to models. We use analogies, we make comparisons, we have even come up with the concept of Design Patterns just to improve communication. While making comparisons can speed communication, we must choose the right comparisons and acknowledge that no single comparison is going to perfectly describe all aspects of what we're doing. After all, if there was, why would you be doing it again?

I was reminded of this last week when I was at a family Christmas party and I heard:

Person A: That stuff is as slow as molases!
Person B: It *is* molases.
Person A: (pause) Oh.

As you can probably tell, the comment didn't add anything to the discussion. While the point wasn't to share an idea and/or convince someone else of a model, I found it painfully familiar to other discussions I have heard.

Software development is confusing to many people and black magic for many others. We have a responsibility to make good comparisons and analogies in order to translate for everyone else. Not only can we communicate with customers better, but it allows us to communicate with each other better.

Think about the models and analogies you're using and ask yourself these questions:

Do the comparisons make sense?

If you're talking about email, comparing it to a postcard makes sense for various reasons: it's cheap to send, it's essentially public for everyone to read, and there's little to no guarantee that it will get there in a timely manner.

Do they add anything to the conversation?

If you have a library which simply wraps a different library to give it a standard interface, don't call it a “wrapper”. That doesn't mean anything and doesn't add anything. Call it the proper name – an Adapter – and compare it to a US to European electrical outlet adapter.

Where do they fail? and Why do they fail?

Software development is regularly compared to constructing buildings, tending crops, waterfalls, and a variety of other things. When you're working with non-physical pieces that can be manipulated at will and have a near-zero transportation cost, these models only work so far.

Can you use other comparisons to describe those areas?

To describe software development, none of the above descriptions capture it completely, but some capture different aspects. Constructing a building gets to the concept of building frameworks and fleshing out the application. Sculpting a statue gets to the concept of removing unneccessary pieces and simplicity. Evolutionary concepts get to the idea of “survival of the fittest”. None of them perfect, all of them useful.

Thanks for reading and Happy New Year.