Technical debt.
It’s when you build software in such a way that will require re-work in the future to “put it right.”
Developers and software engineers generally know the right way to build something, and the quick way of doing it.
Sometimes they are the same thing.
When it’s not – and the ‘quick way’ is chosen, then you accrue techinal debt, which will need ‘paying’ off in the future, or the intangible costs will bleed you slowly in terms of ongoing bugs and inefficiencies within the system.
As a Project Manager with a Consulting Partner, I expect my team to understand technical debt, and have candid conversations with me about why it might be necessary in my project.
I am fine with it as long as there’s a good reason why, with a plan to re-pay that debt as soon as possible.
It’s something I can estimate and plan properly so that we are in a good shape when we get to the final testing phase before handing it over to the client for Acceptance Testing.
As a Consulting Partner, building robust systems should be what we do.
If we take short cuts, build bug-ridden system and poor design, we might as well chuck in our job.
Just like finance and social debts, I never like being a debtor.
And if you work for a Partner, it would be in your best interest to understand the concept of ‘Techincal Debt’, and not use it as a short-cut because we can’t be bothered to do things right.
Or you’ll get a reputation for being a cowboy.
Believe me, in our industry – this isn’t a compliment.
Don’t be a cowboy. 🤠
#projectmanagement
#onthepeiroll
#technicaldebt
#dontbeacowboy