The thing about building a house is that you need to plan everything important in advance. There are many important things, but let’s take one thing, the foundation.
The type of foundation depends on a bunch of variables. If the house is planned near a river or lake, there is a high groundwater level. Therefore, a foundation on piles is needed. Piles cannot support a heavy brick house, so there are no brick houses near rivers and lakes. If the foundation lies above the freezing level of the soil, in winter the soil below the foundation will freeze and swell due to the expansion of water. This can break the foundation, and the house. It is known that in Moscow the ground can freeze by 1.7 meters, and in Novosibirsk by 2.4 meters. Since in these cities the foundation needs to be buried so deep, it makes sense to build basement floors.
In IT, the word “platform” is often used for the foundation. If we look globally, we live in the times of the third platform. If you look locally, every IT product having a future is trying to become a platform. Similar to the foundations of houses, platforms are afraid of groundwater (staff turnover), soil freezing (lack of funding) and much more.
If you need to build several houses and do it beautifully, everything becomes much more complicated. For example, we want five houses and a fountain between them. The architect needs to think through not only important things like the location of entrances, but also all sorts of little things. For example, you need to imagine what will happen to a fountain on New Year’s Eve in Siberia.
If you are an architect and you have drawings signed by the customer, working is easy and pleasant. If the customer suddenly wants to build another floor (and your foundation is not designed for additional weight), you can refer to the fact that this is not what is drawn and agreed upon in the project. There is no need to engage in bidding and arguing once again. There is no need to dig up the foundation and build everything again. It all comes down to the fact that in the construction of houses, the thinking paradigm “we do it clearly according to the documentation” is optimal. This is not always the case in software construction. Still, software is “soft”. The soft one should easily change shape.
In general, house-building analogies can be powerful and tempting for programming, but they have a limit. In any case, such analogies can greatly enrich the way of thinking of a software architect. It’s good when a specialist has a variety of tools that can be used to creatively solve emerging problems.
In the picture below, the classic house layout is first drawn. Below it is a diagram of the components of the task tracker. Such a component diagram can be much clearer than a UML component diagram because it immediately shows the relative size of the component. Instead of arrows, doors are drawn between the components.
(In the next article we will try to navigate the turbulent currents in software architecture of the early 2000s…)