Very few people pay attention or give it a responsible consideration, but when programming, or more specifically, when designing how to implement a software system, there are actually (at least) two types of architectures.
Let us call them functional and non-functional architectures because they are strongly related to functional and non-functional requirements; but there are other names like macro and micro architecture for example. Perhaps there is not much consensus on the concept precisely because it is not deemed much important.
Why is that? For the most part, in modern times, teams of developers are indoctrinated in that the only thing they should be doing is delivering value in each iteration of product development. Rarely a team members is willing to invest efforts on non-functional architecture, more than that, functional architecture is easier, most of the time, teams won’t “reinvent the wheel” and are just combining different technologies available for each purpose (which there are a lot of technologies for every need), and don’t really know what can or should be done at the level of non-functional architecture.
Nevertheless, there are technologies for non-functional architectures as well, but they pretty much stop in frameworks, that although are important, more often than not we even skip some parts of their philosophy or guidelines in order to “code faster”. From my experience in quite a number of companies, and the experience shared by developer friends, the usual popular excuse is “I didn’t have time to make it proper, next time I’ll refactor it”. Were they feeling something more essential was expected of them? Why do developer teams cooperate negatively against their own health?
That leads me to interviews; usually during interviews, technical interviewers only focus at assessing capacity to build functional architecture and if the candidate were able to fulfill a product of a customer need. Requesting demos or exercises in which they have to demonstrate they are able to build a “working” endpoint, or whether they are able to “design” a system and with what technologies, even though technologies are constantly changing and evolving, like it is the perfect thing to measure. When the interview process is formulated in that manner, it is not realizing it is just assessing how well-prepared is a candidate at being interviewed, and their ability to be taletellers of functional architecture.
Because of that, programmers are becoming more and more expendables, and we are digging our own graves. This article is titled with the intent to make an although drastic, metaphorically accurate comparison to hazardous industries from the last century. Mining for instance, they had little care for worker safety and only cared for the output or productivity of the specific mining activity because that is where the money was, regardless of many workers dying. Respectively, the hazards in our case are the lack of non-functional architecture in every code base that keeps growing unmaintainable and uncategorized, which will force us to dig the same tunnel multiple times or have it collapse on ourselves, and that is how, figuratively, programmers are dying.
Much arises from a modern mindset. Many entities, from individuals to big name companies promote indiscriminate programming claiming that “extensive” learning is not needed. Even camps with catchy phrases like become a programmer in a couple of weeks learning a «particular platform». Don’t get the wrong idea, it is a good start to the programmer journey, but do not make it feel like knowing a language or some basics is enough, like it is nothing and there is no science behind it. It is not like learning how to tie a knot, and even knots have science behind them.
It is not a revelation everybody knows that knowledge and education is power. For those who have not experienced it, believe it, knowing more, understanding how those things one knows of came to be, being aware of the extension of one’s knowledge and grasping how much more is yet to be known, makes one feel much better and confident to have any desired job.
Might it be that the ulterior motive of this mindset is to mass produce a docile and cheap labor force of expendable programmers? Wow, that’s evil.
Do not take programming principles as a given. Prioritize science over technology, how to lay and dispose code rather than finishing the working endpoint, otherwise what kind of mess will the code base become when there are hundreds of endpoints? Take into account that technologies have changed in the past and will eventually change again, so do not rush into sticking only to the functional architecture. Study and develop the other side, and do not neglect it on supposedly lack of time or priority. Do not contribute in creating a precarious tunnel of code for our future selves and our fellow workers. Do not work in the mine blindly, for our own sake. Promote developing software into a healthy environment. Unite as programmers.
It is perfectly fine, no, it is a good thing to massively grow new programmers but do not disregard the science and engineering behind it. We have a modern digital world full of software, because people in the past really studied it. It is childish and disrespectful to take it for granted. We have the responsibility to maintain this profession as elevated as it can be, so a programmer can be taken more seriously as it used to be.