How to Leverage Technical Debt
medium.com
How to Leverage Technical Debt
1–10 of 32 posts
Re: How to Leverage Technical Debt
#2The development team at a company I worked for stated they had technical debt. They said they would spend the next year eradicating it. Then didn't even try.
You want to know what technical debt really is? The result of procrastination in the realm of tech.
It's not even worth giving it a funny name like technical debt that upper management doesn't really get. They understand what procrastination is.
You can't spin procrastination. It is what it is.
Re: How to Leverage Technical Debt
#3The development team at a company I worked for stated they had technical debt. They said they would spend the next year eradicating it. Then didn't even try. You want to know what technical debt really is? The result of procrastination in the realm of tech. It's not even worth giving it a funny name like technical debt that upper management doesn't really get. They understand what procrastination is. You can't spin p…
Is someone who takes a financial loan procrastinating paying their bills? Or are they solving a short term problem the best way they know how?
Procrastination may lead to technical debt, but it's not the only source. The biggest source of technical debt is insufficient planning for future product requirements, leading to old code blocking new features.
That's why the concept is called "debt," because it's as if you took out a loan on the first iteration of the product, and then many features later, you're still paying interest on that loan.
So no, technical debt is not purely the result of procrastination. Sure, procrastination, especially in the planning stage, can create technical debt. But even the most productive people, those mythical creatures who never procrastinate, are vulnerable to creating technical debt for themselves. In fact you might argue they're more likely to create technical debt, if they choose to skip the planning phase and jump right into coding.
Re: How to Leverage Technical Debt
#4The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and ultimately pay the money back (with interest).
Now consider technical debt. When you go to your architect and say, "I want you to hack something so that we can get it out the door a month earlier", your architect should respond with, "What are you going to do with that time I give you?" If the answer is, "I just think we need to get to market as soon as possible", then you are doing the technical debt equivalent of spending borrowed money on pizza parties.
As a reasonable architect, I need assurances that I'm going to be paid interest on the loan. If I give you a month, I'm going to need a month and a half back. You need to explain to me how you are going to make that kind of time. If you can not, then the business plan needs rethinking. No respectable banker would say, "Oh, there is a 0.1% chance of success if I lend them the money, but a 0% chance of success if I don't. I'd better lend them the money!" He says, "Come back when you have a better business plan".
The other annoying issue is that complexity in software can grow exponentially. So the cost of repaying the debt can quickly outstrip your ability to pay. Imagine borrowing money and having an interest rate of 1% for the first month, doubling every month. Seems like a wonderful idea to borrow the money, but you better pay it back fast.
The problem with technical debt is not that you must avoid it at all cost, it's that you must think very hard about whether or not you can afford it. If you can't, you should avoid it. If that puts your company out of business, then you need a better business plan.
Re: How to Leverage Technical Debt
#5The development team at a company I worked for stated they had technical debt. They said they would spend the next year eradicating it. Then didn't even try. You want to know what technical debt really is? The result of procrastination in the realm of tech. It's not even worth giving it a funny name like technical debt that upper management doesn't really get. They understand what procrastination is. You can't spin p…
Is someone who takes a financial loan procrastinating paying their bills? Or are they solving a short term problem the best way they know how? Procrastination may lead to technical debt, but it's not the only source. The biggest source of technical debt is insufficient planning for future product requirements, leading to old code blocking new features. That's why the concept is called "debt," because it's as if you t…
>> insufficient planning for future product requirements
This covers both low prioritization and procrastination, the former of which I think is what you're getting at, and the latter of which I think is what purpled_haze is talking about.
It's the difference between "we'd like to clean up this technical debt but these new features are too pressing" and "we have nothing else going on, we're going to clean up this technical debt..." and then never doing it. In my experience, the latter happens because no one ever generates a real execution plan to get it done, often because there's just no reward for doing so.
Re: How to Leverage Technical Debt
#6The development team at a company I worked for stated they had technical debt. They said they would spend the next year eradicating it. Then didn't even try. You want to know what technical debt really is? The result of procrastination in the realm of tech. It's not even worth giving it a funny name like technical debt that upper management doesn't really get. They understand what procrastination is. You can't spin p…
Disagreed.
Procrastination is letting for tomorrow what you know you should be doing today.
Technical debt is what happens when you try to do today what is due for tomorrow but you know deep down it cannot be done properly in less than 3 days. Then you deliver and you pray that none will be looking close enough to notice the difference.
What the article says is that technical debt is actually a good thing if whatever you are doing today has more than 50% chance of being thrown out of the window by the end of the month. If is better to try 20 crappy things, discard 15 and keep 5, than to do 8 good things and keep 1 or 2.
But this is only true when people take next month to fix the 5 things that were found to work in the past "sprint". The reason we all hate technical debt is because virtually no one does that.
Re: How to Leverage Technical Debt
#7The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and…
It's great to able to articulate that, but in the real world this sort of thinking does not actually hold much weight. Launching a month early is a good thing.
Re: How to Leverage Technical Debt
#8The best way I learned to deal with technical debt is to package it into securitized collateral debt obligations and find a product manager who can structure them into traunches and then find a QA manager who can rate these traunches and set up a regulatory framework with in which project managers can provide liquidity necessary to deal with it. If that does not work try to find an executive who can issue an Asset backed commercial paper that developers love. Now at this point the debt is handled so well it no longer is an issue.
Re: How to Leverage Technical Debt
#9The development team at a company I worked for stated they had technical debt. They said they would spend the next year eradicating it. Then didn't even try. You want to know what technical debt really is? The result of procrastination in the realm of tech. It's not even worth giving it a funny name like technical debt that upper management doesn't really get. They understand what procrastination is. You can't spin p…
Is someone who takes a financial loan procrastinating paying their bills? Or are they solving a short term problem the best way they know how? Procrastination may lead to technical debt, but it's not the only source. The biggest source of technical debt is insufficient planning for future product requirements, leading to old code blocking new features. That's why the concept is called "debt," because it's as if you t…
I don't know if "debt" or "procrastination" are really the correct words. It seems to be somewhat in the middle of the two, where the problem comes from "We'll take care of that in the future." where the future never comes.
A good example of that might be in log refactoring. I recently quit a place for what amounted to a complete lack of interest in correcting bad logs. After spending 8 hours trying to fix some non-prod issues and being completely halted by timeout errors, I was told "Those errors are fine, they even happen in prod (!!!). We talked about fixing it, but agreed to do it way further down the line." So, not really procrastination or technical debt, but something similar since it's 'debt' and 'procrastination' are simply symptoms of a larger problem.
Re: How to Leverage Technical Debt
#10The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and…
Sure, except when your architect has some sort of contention, whether it's time, patience, or ego. Last time I had a decent idea to pitch, I pitched it to the architect twice - first time, it got completely thrown down. Second time, practically same pitch, except it was approved. I genuinely feel like a month was lost because of that.
There's something to be said for "just doing it", and so so many times have architects completely gotten in the way of making good progress.