What Modeling Can Do for You

Imagine the following situation –it’s not very common, but that’s what the word “imagine” is for. One day you’re at home, bored, so bored that you come up with the crazy idea of turning on your computer, just because. But not to browse social media, play games, or chat –anyone among the common run of mortals who saw you would say you’re a bit weird. And you tell yourself: “I’m going to bang out some code” (dictionary-kicking developer jargon for the act of programming) –at this point one of those common mortals has surely already given you a very strange look.

Leaving aside the unimportant people who find all this weird, let’s focus only on you and your idea. You’ve had an idea, for example to program a music player with two buttons, a “Play” button and a “Stop” button to start and stop the songs it will play; you’ve also thought about adding a timer, to know how far along the song is; and surely a few other things too, but that’s enough for us.

The crappy music player we imagined. It’s a long way from working!

Now, you want to make it happen. Your motivation could be anything, from learning to selling it once it’s finished, or even both at once, among other motivations. You know how to program and you can do it, and you want it to be professional. But you’ve already failed, it won’t be professional. Why?

 

Anyone in your position would do exactly the same thing. Have an idea and carry it out in the shortest time possible. Do it chaotically: sit in front of the screen and start throwing down lines of code, deleting some and replacing them with others because we’ve thought of something even better –it ends up being endless and the program probably never gets finished. That’s why some of the most common questions come up: Why do it professionally, with documentation, with modeling techniques? I won’t see the result until much later, and anything that sounds professional smells boring, feels like a chore, and nobody knows how to do it. It’s very comfortable to just start programming, and for a simple program, like the proposed music player, all you need is to start coding and, if you handle the language well, it will be done in an afternoon. It’s true, it’s not worth modeling or documenting something so trivial; you lose more time than you gain.

But what would happen if we had more than one developer? They could be friends with a common goal or employees of a company. And what happens if our project is no longer a simple music player with two buttons, because we’ve come up with something monumental or because new ideas pop up while we write code? Like a player with an online store, comments, ratings, favorites, sound filters, a cover art viewer, a timeline, sound diagrams, and many other features –since we want a product that is attractive on the market, that sells well, and is unique and original. This is where we’ll face problems that have terrified us since the dawn of time.

Long ago, let’s say, a pottery maker and seller from the Paleolithic period made vessels one by one. It was a slow process, but good enough for the competition back then, and business was good: you traded a jug for other goods. The customers were just enough for the production.

Making vessels one at a time without models. It takes a long time and they all come out different, even if from a distance they look the same.

This is similar to just sitting down and writing lines of code, building the program directly –just like a Paleolithic potter made clay pieces directly, without blueprints, sketches, or help from others. With one person it works, it’s relatively simple, and it gets done fast. Blueprints in programming? What the heck…? You’ve surely asked yourself, but let’s not get ahead of ourselves, we’re still in the Paleolithic.

 

Centuries went by, and more labor was needed to make bowls and other clay pieces. It was a growing business. But the problem remained: each potter made a single vessel, simple pieces, each one however he felt like, in whatever size he wanted. Production had to speed up, since customers wanted things fast. Customers also wanted standardized measurements, so that all container pieces, like vessels or jugs, would be the same size and identical. To try to solve all these problems, the first models or designs began to be created.

Let’s travel a few centuries into the future, specifically to the 15th century BC, where the rising civilization was Rome –computers didn’t exist yet, and the Antikythera mechanism doesn’t count. The Romans began using the well-known amphorae to transport liquids. Even then, the Romans standardized a shape (narrow neck, two handles) and a capacity (32.3 liters) equivalent to one talent. So every amphora potter had to respect those measurements, to follow a model.

The usefulness of models may not be clear to you. After all, you can simply tell the workers how you want the object and they’ll make it, so why more? Saying that is almost a model. Almost, because as a manager you could say “make amphorae” and that’s not a model; saying “make amphorae identical to this other one” is almost a model; and explaining “make amphorae with these exact measurements” is a model.

We must never forget that we live in a society, and to do big things we need many people who agree with each other.

Let’s imagine for a moment that no blueprints have been made and there are two workers, one who makes amphorae and the other who makes stoppers. The amphorae are made by hand without following models. So the worker making the stoppers, in order for them to fit the amphorae, has to wait until an amphora is finished, and only then make the stopper that fits properly. This is very inefficient, since while the amphora is being made, the stopper maker has to wait. Credit: Amphora images taken from Wikipedia and modified by Jarroba.

A model is an idea you want to turn into reality, which is the same as a blueprint, a sketch, a diagram, or anything else that sits between what you want to make and the initial idea of making it. Therefore, modeling is making models. This makes production easier and faster, as we’ll see. You don’t have to invent from scratch something that may contain many errors due to improvisation; it has already been thought through in advance, and many or all of the problems that could appear when creating the modeled thing have been bounded or solved in the model. In other words, everything has been designed on paper, thought through on paper, and improved on paper –you’ve surely thought of the example of a house’s blueprints. All that’s left is going from paper to product.

Let’s go back to the 15th century BC, with the Romans who wanted to make amphorae. To do things right, the steps to follow are:

1. Idea, the what I want to make: I want to make an amphora.
2. Model, the how to make it: How do I make an amphora.
3. Manufacture, the making: Make an amphora.

The three steps to build an amphora using the modeling technique. Credit: Amphora images taken from Wikipedia and modified by Jarroba.

This had other advantages for our amphora makers. An amphora had two separable parts: the ceramic container and the clay stopper. With the model, the people making the containers could abstract away –ignore completely, and probably not even know how– from making the stoppers. Other makers, probably at the opposite end of the city, were in charge of making the stoppers. So the container makers would possibly never be in contact with the stopper makers, and might not even know what the stoppers looked like, and vice versa. That’s why a model was necessary, so the stopper makers knew the measurements of the amphora’s neck, and the container makers knew the measurements of the stoppers –that way they would fit perfectly; otherwise the amphora makers would surely have gone bankrupt, since nobody wants amphorae with stoppers that don’t fit.

 

It also increased production. While some makers made containers, others made stoppers in parallel –they didn’t have to wait for each other to finish. Finally, at an agreed place, there would be people in charge of receiving the containers and the stoppers to join both pieces; then they’d send the complete product to market.

If we go back to the simple example of the two workers, one making stoppers and the other amphorae, each with a blueprint of how to make things, they would make them identical, without the mistakes of improvisation. And not only that: knowing the measurements, both makers can do the work simultaneously, without waiting for the other to finish. That’s more productive, since the work is finished sooner and both workers are working at all times. Credit: Amphora images taken from Wikipedia and modified by Jarroba.

If you’ve understood the usefulness of a model, you’ll have deduced the three fundamental steps to make the music player:

 

1. Have an idea: I want to make a music player.
2. Model the idea: make the blueprints and diagrams of the music player.
3. Build the idea: make the music player.

Furthermore, time has taught us that with a model you get:

• In-depth knowledge of the product you’ve conceived, which makes it easier to understand something complex. An idea is something blurry and short on detail.
• Errors corrected before production starts. In a blueprint you can see what might fail, erase it and draw something better.
• An estimate of the tools needed and the approximate production time, plus other things you can deduce. From looking at a blueprint you can deduce which tools will be necessary, since if you see a nail you’ll surely need a hammer.
• Easier communication with the producers. This lets you know up front what can be produced in parallel and therefore shield each producer from other parts that don’t concern them. Once the boss saw the amphora blueprint, he would send one factory to make stoppers and the other the containers, as mentioned.
• Once the model is polished, it can be reused. It can be combined with others to create more complex models or to improve existing ones. Years later, with the amphora model, jugs and cork stoppers would be created.
• It will surely solve similar problems, or help create highly refined models of other similar products. The container-and-stopper model for liquids worked very well, so bottles, drums, etc. came next.