If we had one minute to build as tall a marshmallow-toothpick tower as possible, we may use 90% of our time building the tower and 10% of our time planning the tower’s structure. If we had one week to build the tower, our time usage changes: we may use 60% of our time building the tower and 40% of our time planning the tower’s structure. As a project’s complexity increases, the percentage of time in building the project’s individual features decreases and the percentage of time in building the project’s structure – its foundations – increases.
This principle – project complexity, up to a certain point, is inversely proportional to time allocated on building individual project and proportional to time allocated on planning and building supporting infrastructures– also applies to programming projects. It is well known that in large projects, 80% of time used in developing software is used in debugging and navigating through files. (Perhaps this is why Vi’s Normal mode is navigational instead of editorial!)
One question comes to mind when we examine this principle: wouldn’t it make more business sense if the time used to plan and build supporting infrastructures were used instead to develop specific features? After all, customers buy a product because of its features, not its internal structure.
For projects that are not intended to be expanded, such as quick proof-of-concept or one-time use or school projects, using time to build a scalable structure instead of to build the specific features may not necessarily be the best choice because a scalable structure isn’t necessary since, by default, the project won’t be expanded. However, for larger projects, especially software projects, developing the structure actually decreases future development time, accelerates debugging, and improves readability.
These benefits are not trivial. Faster debugging often means finding bugs up to an order of magnitude faster. Increasing readability not only helps new members learn the project’s intricacies, but also assists members to see the code’s big picture instead of confusing them with the nooks and crannies of spaghetti code. In the short run, developing a scalable structure might seem to be unhelpful because the code, at that point, is already easy to understand without having a robust structure, and development time is not being used on building features to attract customers, in the long run, the time taken to. In the long run, a scalable structure enables easier future code changes and will actually more than compensate the days and weeks spent staring at ugly code wondering what its purpose is.
In life, learning a topic’s foundations is helpful and increases our ability to understand more indepth topics. When learning history, we can jump straight to the dates and events but if we first learn about the context leading to events, the reasons for conflicts, similar events that had occurred in the past, and other foundational materials, our understanding of history would be much richer even if we knew less dates. When we learn how to cook, we can directly try out different recipes but we develop greater cooking skills by first taking time to understand the effects of ingredients, the reason for mixing different sauces, the texture of various food. In doing so, even if we memorized less recipes, we intuitively understand the food, which gives us knowledge to modify existing and invent new foods.
With knowledge of a topic’s fundamentals, we can more efficiently learn more advanced materials, analyze our methodologies and others’ methodologies, combine knowledge from multiple disciplines to invent or innovate, and teach our knowledge to others. There are many ways to learn the fundamentals: by reading (eg, books, articles), by listening (eg, classes, seminars, mentors), by doing (eg, experimenting).
In summary, for quick or limited-use projects, building the project features is more important than building a scalable infrastructure. For complex or long-term projects, building a scalable infrastructure can be as important, if not even more important than, building its features.