I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
Yes. To be able to effectively communicate the importance and priority of dealing with technical debt you need to figure out how to quantify the cost of not doing the work and the added value of doing it. In other words, you need to give non-technical decisions makers a way to compare their list of priorities with yours. For example, you could come up with something like: "if we don't fix this issue, we will never be able to scale past X number of requests per day. Given the traffic trends, we'll be there in Y months..."
So... the trick is to convert technical needs into non-technical values.
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.
Yes. To be able to effectively communicate the importance and priority of dealing with technical debt you need to figure out how to quantify the cost of not doing the work and the added value of doing it. In other words, you need to give non-technical decisions makers a way to compare their list of priorities with yours. For example, you could come up with something like: "if we don't fix this issue, we will never be able to scale past X number of requests per day. Given the traffic trends, we'll be there in Y months..."
So... the trick is to convert technical needs into non-technical values.