Lack of pragmatisim

Many developers often feel pain in their jobs when technical debt reaches critical levels, and they quickly become obsessed with blaming the code as the source of all their problems (especially when it is not their code). The problem is that technical debt is not a disease but a symptom. Several factors cause technical debt, but the most significant is time pressure. Time pressure itself is often the result of unhappy customers. Sometimes fixing technical debt is a waste of time because as long as we don't cure the disease, we will continue to create unsustainable levels of technical debt. What is the disease? In most cases, the disease is a leadership/culture that focuses on outputs over outcomes.

Seeing technology as a goal (not a tool) is a symptom of a lack of pragmatism. Being a pragmatic programmer means approaching software development practically and sensibly based on the specific context of the project and the needs of users and stakeholders. They can make trade-offs and compromises, balancing the competing demands of time, budget, and available resources, and make decisions based on what is feasible and achievable in the given context. A pragmatic programmer focuses on delivering working software that meets the project's requirements rather than adhering rigidly to theoretical principles or dogmatic rules, pursuing perfection or theoretical purity. A lack of pragmatism can lead to premature optimisations, feature overload, over-engineering a product, being difficult to maintain, and ultimately failing to deliver value to users and stakeholders.