Structure

Everything we create is subjected to the test of stability. If we carelessly staple many bricks on top of each other, not only won't we build a house, but a falling brick may be the last thing we see when the wind blows. Earthquakes and floods will test the base of the house, rain will test the top, wind will test the walls on the side. Noise from the neighbors will test how stable the rules of good citizenship are. If they aren't, building a stable house is still unwarranted, especially when everyone could break into it. Proudly declaring yourself a Ferrari owner midst an average of Volkswagen Golfs will likely leave you without a car. This shows that the structure within the context matters a lot.

Thinking in hierarchies is just one way to organize the complexity as we perceive it. Each room has furniture, which contains various objects, which keep other things as well. We know which is where or in other words, where in this idealized hierarchy to look for once we need something. Drawers are subdivided to keep different kinds of utensils, so that the most frequently used items like spoons and forks are more conveniently accessible than infrequently used ones like can openers or corkscrews. Once we learn the structural organisation of a home and our model of it is fairly accurate, finding the path from one room to another becomes easier. And so complexity becomes slightly more manageable if not completely overwhelming. The more we train ourselves to be able to retain more complex models, the better we become at it.

A refrigerator also needs to be well-organized, so that we can find quickly the products we need. Relying on our visual system to find the right item is not enough, since some items may remain hidden behind other ones. But our mental model tells us that the last time we have put product A behind product B, so it must still be there, if not already consumed by someone else. So we know where to look first.

Finding the right file is possible only through the structure of a directory with an accurate label. We may have multiple files with the same name, so there is no way to know in advance which one we need. A search would return all similar looking names, which doesn't tell us much. But we may have an idea of the (approximate) directory label in which that file is located. This label is likely to be based on a model we have created for ourselves based on how important we perceive our data to be. By introducing structure through the labels, we can find more easily both individual and related items.

The common theme behind all these cases is the derivation of the model from reality as a means to enable structure. But it is more interesting to observe how a mental model (head-first) could be used to create real products. If we can hold complex structure in our head, this can enable the creation of products that rely on reading from and writing to this structure. Then, despite all complexity, we would know where the blinking on this structure occurs, based on how we chose to arrange the concepts and things in our head. If we look at disk defragmentation software, we see that at the start a lot of different regions are blinking, which suggests that the software is inspecting the structure of its given world. But once the model of it is built, the defragmentation process becomes much more linear, with only occational reads from distant locations. This suggests that given incomplete information, we can only proceed in a suboptimal way. The structure itself enhances our decision-making.

As we have already seen, interfering with other people's structure and their own understanding of the world is never a good idea, unless we want to slow them down. This is often not well understood in organizations where people move fast from one project to the next or change from one team to another. This way, there is no sufficient time to build any model or architecture that will stand the test of time.

A monolithic codebase makes it hard to make changes or to contribute. Trying to separate our concerns while working in code is another way to create a structure where everything can be found quickly. It is helpful to think in terms of “maximum margin separating hyperplane” to understand how the various responsibilities within the system can be clustered before we start to manually assign individual files to them. Then, the proper labeling scheme will naturally fall into place. For instance, all operations touching the database would belong to the Model cluster, all layouts to the View cluster and all interactions to the Controller cluster. MVC is just an idea, which everyone understands differently, but it illustrates well the attempt to keep the concerns separated by a wide margin. As the number of clusters grows and they increase in size, they may move more closely together, which will increase the potential for mistakes.

Knowing when structure works against us is valuable as well. Too much of it can slow down processes or lead to projects with missed deadlines. Sometimes a system can fall under its own weight, created by excessive structure. This makes it hard to understand and leads to companies of many people, none of which truly knows how things work in their entirety. Too much organizational structure inhibits creativity and can lead to increased bureaucracy.

While trying to ship faster, we often penalize projects that would benefit from more structure. The release itself becomes the celebrated event behind which the quality of work is actually deteriorating and especially so after the next batch of changes is introduced. “We need it fast and now” becomes a tool for stressing and concurrent brain hacking on the structures that the programmer is trying to manipulate in mind, which is dangerous for any software project. When overworked/tired programmers are unable to hear their own voices, their choices and the quality of their products begin to suffer.