A lot depends on who exactly needs to be convinced and what is most important to them. An engineering manager is going to see it differently than a business executive.
@Chapman 's point about it being like financial debt is a good one, because it's the same core concept: you're borrowing against your future to achieve a goal in the short term. Often it is accepting that code will be harder to work in down the road in favor of hitting a deadline. Just like financial debt, you'll be buried in interest if you don't eventually start paying it off.
That's more of a high level concept, but you also want to start thinking about it in tangible terms. Can you point to specific examples of a bug that was introduced or a deadline was missed due to working in code that needs a refactor? Even better, can you assign a value to it? Perhaps down time in the app from a bug, developer hours (which ultimately == $$)?
At the same time, you can be as convincing as possible, but some people or work cultures just aren't willing to listen (which means you have another problem). Your happiness and stress are also two factors in this, and if a company wants to retain you for the long term, it is in their best interest to make sure that tech debt of all things isn't causing them to lose employees.
Can you point to specific examples of a bug that was introduced or a deadline was missed due to working in code that needs a refactor? Even better, can you assign a value to it? Perhaps down time in the app from a bug, developer hours (which ultimately == $$)?
That's excellent, gathering some data to show the financial cost to the business due to existing technical debt. I think that goes a long way, especially for upper management.
Yup. You can roughly log how long it took you to fix a bug or how many bugs were created as a result of a change and multiply that by an average hourly or daily rate a company is paying for a developer. Especially if it impacts multiple developers!
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.
A lot depends on who exactly needs to be convinced and what is most important to them. An engineering manager is going to see it differently than a business executive.
@Chapman 's point about it being like financial debt is a good one, because it's the same core concept: you're borrowing against your future to achieve a goal in the short term. Often it is accepting that code will be harder to work in down the road in favor of hitting a deadline. Just like financial debt, you'll be buried in interest if you don't eventually start paying it off.
That's more of a high level concept, but you also want to start thinking about it in tangible terms. Can you point to specific examples of a bug that was introduced or a deadline was missed due to working in code that needs a refactor? Even better, can you assign a value to it? Perhaps down time in the app from a bug, developer hours (which ultimately == $$)?
At the same time, you can be as convincing as possible, but some people or work cultures just aren't willing to listen (which means you have another problem). Your happiness and stress are also two factors in this, and if a company wants to retain you for the long term, it is in their best interest to make sure that tech debt of all things isn't causing them to lose employees.
That's excellent, gathering some data to show the financial cost to the business due to existing technical debt. I think that goes a long way, especially for upper management.
Yup. You can roughly log how long it took you to fix a bug or how many bugs were created as a result of a change and multiply that by an average hourly or daily rate a company is paying for a developer. Especially if it impacts multiple developers!