Part 2 in Lucas Moser’s Four Part Series.
In my pre-software days, the word model would have made me think of model cars. Specifically, I remember model kits that included hundreds of plastic pieces that needed to be cut apart with an Exacto knife, glued together, and painted to resemble the actual car. In fact, resemblance was the primary goal of the modeling process itself. Car aficionados could create a small plastic facsimile of their favorite automobiles with doors that open and a hood that lifts.
How do you think companies created these model kits? Consider first model designer A. He snaps a picture of a 1956 Ford Thunderbird, takes that picture back to the shop and starts designing molded plastic pieces. His final product may resemble the real thing, but there will likely be flaws. The picture may have been too blurry to get all of the detail of the Thunderbird logo. The picture probably wasn’t from the back, so the designer missed the detail of the continental kit and the location of the exhaust. Maybe the model’s hood is molded shut because the designer had no idea what to put inside. A kid who just wants to roll his T-Bird model on the floor probably won’t miss these details, but the lifetime Ford fan will.
Now consider designer B who spent a full day with a Thunderbird. He measured the size of the wheel relative to the tire and the size of the tire relative to the wheel well. He took note of how the convertible roof attaches and detaches from the car, brought a mechanic with him who explained everything under the hood, from the engine to the drive train. He talked to the team that worked on the original car. He found out what colors of paint were available, what the texture of the seats are like, and honked the horn a few times. During this full inspection he probably learned a lot of things that had no impact at all on his model, like what the engine sounds like and what the shocks feel like when the car goes over a bump.
It is clear that designer A is missing key components for a rich model. Based on the picture, he must piece together what is seen in the picture with what he already knows about cars. In the photo, he sees that there are two wheels, but common knowledge tells us there are probably four. He can’t see the pedals, but we know there are at least two of them (maybe three if it is a manual transmission). The take-a-picture approach tends to rely on assumptions that may or may not be true. Code is then written and features are implemented without knowledge of the context in which they’ll be used. This is what happens when we simply design toward requirements. On the other hand, while designer B certainly has not captured each and every detail regarding the Thunderbird, he is certainly more prepared to start designing his model. At this stage he may not understand every minute detail of the system, but he does understand what components make up the whole and how they interact. Here he can start to make educated guesses about how the system will be used and how it will evolve in the future. He is better equipped to add built-in flexibility features where the requirements are most likely to grow and keep designs simple in areas of the system that may not be applicable to the application.
Next, we will discuss how technology professionals understand this concept.