Why I Love Modeling

I'm talking about drawing up a picture of the technical details of a solution before you start making it.

Let's say you were building a home theater in your basement. While it's certainly possible to make a list of everything you'd like the home theater to do -- say show movies, make snacks, seat 12 people, have easy viewing for everybody, etc -- and do one of these things at a time, your problem is that all of these things need to exist at the same time in a limited space when you are complete. Everything must integrate and conform to various constraints.

Turns out this is the same problem we have when making technology solutions. If it's more than just a couple paired-programmers, you usually have all sorts of external constraints and it's critical that all of the pieces of code work with each other. Same goes for other complex systems like the Space Shuttle, a Boeing 747, or a fax/copier. You don't just start building a 747 by making a tire. You start by sketching out what the finished solution might look like, and then you work to make the solution look like the picture.

Would you build a home theater by going to Lowe's, picking up a chair,
throwing it in a field, and then building a screen in front of the chair,
eventually building a house addition?
If so, you should stay away from construction work. First you sketch, then you work

This reminds me of the Five Cs of modeling, four are good, and one is bad.

• Communicate. Pictures communicate a hundred times more effectively than words. One drawing, which you could explain in ten minutes, can cover the same amount of information as a 50-page word document. And let's face it -- nobody reads those anyway
• Collaborate. Want to work together on how the tiering is going to work between your new reference architecture and your remote object pool? Need to figure out how document flow is going to change between a dozen divisions once new federal regulations come out? You can't collaborate about things you can't communicate about, and modeling is the best communication tool we have.
• Consensus. If you are part of a group evaluating a technical solution, having a diagram gives you something to point to. If there's a sticking point in the discussion, make sure the answer is prominent in your model.
• Coordinate. It's common to have different people work on different parts of the solution. The best way to delineate who does what is to show them. Pictures speak louder than words.
• Control. This is the one everybody messes up. Once you get the idea that pictures can describe technical things a lot better than words, once you really get it, it's very natural to fall in love with the idea that pictures can do anything. You start trying to diagram every little thing you possibly can. This tendency is worse if you have a modeling tool and a lot of free time on your hands. Danger Will Robinson! Danger! While pictures are great, they're there to do something, like drive the four other Cs. They're not there to control the universe. Always use things for a purpose. If you know why you are doing something, it's a lot easier to know how much of it to do.

Conversations drive agile, and modeling drives conversations.

Frequent lightweight sketching is the best thing since sliced bread. You can get more done, faster, and with fewer misunderstandings and repeat conversations. There's no right or wrong way to do it -- if it works for you, it works. So next time you're having a complex conversation, draw it out.