I don't have a strong preference for any programming language or technology. I believe in using the right tool -- whatever it might be -- for solving the problem.
TL;DR; Define SLAs for your software/service/etc and use that to plan how technical debt should be addressed.
It's true that our time to work on a given project is finite, hence improving our ability to identify the most important problems caused by technical debt is essential. Only then can we make good decisions about how and when to address technical debt.
Not all technical debt is the same, e.g., there's technical debt created accidentally and without being aware of it, there's another kind which is created wilfully but with good intentions, yet another kind created wilfully by negligence, etc.
Also, not all software is equal, IMO critical infrastructure needs to have stricter Quality Control than other non-critical systems.
What is really useful, is to have the ability to track the impact of the technical debt, we can then plan resources to fix/improve things a way that's proportional to the magnitude of problems it generates.
These ideas come from the field of Cybernetics/Control Theory, the critical component I think, is to establish a feedback loop in which the "negative impact" of technical impact is given a numerical value, and that is fed into the process that creates the systems until this "negative impact" is kept below a certain threshold.
Quality of Service is the name of the game.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
TL;DR; Define SLAs for your software/service/etc and use that to plan how technical debt should be addressed.
It's true that our time to work on a given project is finite, hence improving our ability to identify the most important problems caused by technical debt is essential. Only then can we make good decisions about how and when to address technical debt.
Not all technical debt is the same, e.g., there's technical debt created accidentally and without being aware of it, there's another kind which is created wilfully but with good intentions, yet another kind created wilfully by negligence, etc.
Also, not all software is equal, IMO critical infrastructure needs to have stricter Quality Control than other non-critical systems.
What is really useful, is to have the ability to track the impact of the technical debt, we can then plan resources to fix/improve things a way that's proportional to the magnitude of problems it generates.
These ideas come from the field of Cybernetics/Control Theory, the critical component I think, is to establish a feedback loop in which the "negative impact" of technical impact is given a numerical value, and that is fed into the process that creates the systems until this "negative impact" is kept below a certain threshold.
Quality of Service is the name of the game.