6 ms·

The 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 an

The 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.

x5n1 11y ago
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.
- cunac 11y ago
  not necessary. if you launch early a crappy feature with a ton of problems it is actually very harmful. time to market is just one dimension of a trade offs you need to balance if you want to succeed
  - mikekchar 11y ago
    I often tell my management, "If it doesn't need to work, I can get it to you any time you want." Everything other than that is a cost/benefit analysis. To be honest, it's hard enough writing a reasonable sized program and not ending up with a horrid mess when I'm doing my best. I'll always recommend giving up functionality over quality if early release is desired. It's easy to add functionality later. It's hard to add quality.
bpchaps 11y ago
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.
- mikekchar 11y ago
  It is both fortunate and unfortunate that there is a conflict of interest between entrepreneur and architect. As an entrepreneur, your job is to make money. The product is actually secondary. Risk is totally acceptable because you can start 20 companies and as long as 1 of them makes a huge payback, you are in the black. Architects, on the other hand make products. I once was interviewed by a firm that asked me a pointed question about what I did to stop a failed project from failing. My answer was that I gave the best information I could, but that I left it up to the business to decide whether to fail or not. I still think that's the right answer, but it lost me the job. As architects/programmers, we do not succeed by making money. We succeed by writing software. Several times in my career I have been hired to write shells of programs -- demos that will secure funding, knowing that the underlying software was essentially a lie. It just needed to be impressive and potentially disruptive. Probably the company who would shell out for it would cancel it the first chance they got anyway. Is it the type of software I would like to work on? No (though it did pay well ;-) ). In any case, that tension is bound to exist. As long as there is good communication and honesty, the tension can provide good results. One of the first questions I ask in a job interview at a start up is, "Do you intend to make a product?" The second question is, "Do you intend to make the product successful?" The questions about technical debt are only really relevant if the answers to those questions is "yes".
  - bpchaps 11y ago
    Honestly, I feel you're making a much larger abstraction than what exists in reality (or maybe what SHOULD exist). Not to say that the abstraction doesn't exist, just that you're a bit too far in the othering-realm for my tastes. There's definitely a middle ground in there where the semantic difference between entrepreneur and architect doesn't exist - where good work and good ideas "are", regardless of how far you swing on that spectrum. I agree that the distinction between the two types of individual is necessary, but an over-use of it is an easy way to lose out in the long run. The question about what you did to stop a failing project is an odd one and probably completely ineffective. If that's the reason they didn't hire you, take it as a good thing. There's too much nuance for it to be considered useful without other considerations. My recent situation was that I pushed too hard to stop a failing project and was socially cast out. By the time the senior staff noticed that my suggestions actually made sense and weren't batshit extreme, the social dynamic was too much and I left. On your last point, I'm not sure that would be a useful question, either. It's so incredibly for a linux lead to say, "Our infrastructure security has no technical debt", for example. It's easy to say, but impossible to prove without being at the company for a while, even for an in-the-mud admin. Hell, that's what happened at the place I just left.
p4wnc6 11y ago
This is a great way of putting it! It's true that many middle managers and business/sales people do not respect this line of reasoning, but that is their mistake rather than a genuine or well thought out business decision -- which is why it bites them in the end. I would take this further and say that it's often a matter of professional disrespect to pay the architect's skepticism such little heed as to override the architect's vote to constrain feature creep. Self-discipline is hard! One of the most challenging aspects of this in real development jobs is that shrewd managers and/or business and sales workers are very good at deflecting blame and creating political situations in which they are able to pretend to have supported the "right" choice no matter what the outcome. So, very often, when features get hacked into the system against the architect's advice and it predictably causes untenable debt growth and parts of the system fall over, what is the first thing you hear? That it is the engineers' fault for not building the system correctly. It's very rare that an architect can successfully communicate the problem of excessive feature growth and convey after a system failure that it was not really the engineers' fault, rather the fault of everyone forcing their poorly conceived features to take priority. In a healthy development environment, everyone should be hearing "no" very, very often when asking to add features, especially when they come to you as if it is a big emergency that some market phenomenon mandates that the feature must be added right now. If you find yourself in an environment where your employer does not empower you, as a developer, to say "no" in that situation definitively, then rather than trying to fight any blame wars about whose fault a system failure was, just get your resume ready and leave. There's no need to put up with that sort of poor engineering culture, and plus, wouldn't you rather put your name on something of quality instead?
jameshart 11y ago
Interesting to place the technical debt creditor/borrower relationship that way round: often it seems that it is seen as being the engineering team who are the debtors, and the debt is owed to some sort of abstract entity - possibly the codebase itself. The developers wind up going to the business and begging for the time to pay down some of the debt, like a college kid going begging to dad to help pay down the credit card after they ran up too much of a bill. I much prefer this characterization, where the engineering team are the lender, and they can call the business in to confront them with the unpaid bills that are coming due and demand a structured plan for how they're going to clear down some of their debt.
chrisabrams 11y ago
What happens when the architect doesn't have the luxury of pushing back? As in, the business will make the architect's boss bend over if the architect says no?
- mikekchar 11y ago
  Ed Yourdan summed it up very well in one of his books. I don't actually remember which one, so I will try to summarize it, but the quote is worth looking up. If you think that the project you are going to work on will fail; if you think that the work you are doing is crap; vote with your feet. Your time is precious to you. You only have so many years in industry to work on interesting projects. Don't waste them. But there are times when the situation is not perfect, but you still don't want to leave. These can be good times as well. If the project has little or no chance of success, why not experiment with some unconventional techniques? It could be your last chance to do something like that. Working in a group which is failure tolerant can be liberating as well. Finally, make sure that you fully understand the business decisions before you go overboard. In the very first start up I worked in, the management pushed estimates that were wildly inaccurate. We'd say that it would take 4 months and they would promise 1 month to the customer. We failed every single time. When we finally got to a product launch, many years late, I asked the CEO if he wouldn't have rather known at the beginning how long it would take. He smiled and replied, "No, of course not. I would never have gotten funding if I told people that it would take this long." There are things that we, as programmers, know very well. There are things that we do very well. This is also true of business people. Sometimes we, as programmers, can't understand what they are doing because we aren't business people. Sometimes in our hubris, we think we know better than them. Knowing who to trust in these kinds of situations takes time and experience.
  - cageface 11y ago
    Deliberately misrepresenting the amount of work it will take to build something is unethical and perhaps even fraudulent. I hate to see people do this kind of thing because it gives our industry a bad rap and could eventually lead to cumbersome regulation or certification. It's true that software budget estimations are by their nature educated guesses at best. But we should still make an effort to be honest about them.
dreamfactory2 11y ago
I don't disagree with the gist of your comment but time to market is generally massively undervalued (and particularly by technical folk). It's more often than not a great reason for taking on tech debt (not to mention that early releases also constrain scope to smaller chunks).
- lumpypua 11y ago
  I totally agree that time to market is hugely important. The dynamics of getting to market are complicated and I don't agree that tech folk undermine them to any special degree. If you're an engineer with a few years experience, chances are you've been smacked by being too conservative or too loose with tech debt. Good contextual use of debt is a key part of the "senior" in any senior engineer. I'm happy to be "sloppy" and fast at the right moments. My experience has been that business people value time to market, but only if they can offload the costs to engineering by taking on tech debt. When asked to put their money where their mouth is and pay for more engineers or cut scope, often the business side will balk. It's an annoyance when non-technical leadership perennially sees tech debt as a way to get a free lunch. Ain't no free lunches.
- deleted 11y ago
  [deleted]
deleted 11y ago
[deleted]

x5n1 11y ago

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.

cunac 11y ago
not necessary. if you launch early a crappy feature with a ton of problems it is actually very harmful. time to market is just one dimension of a trade offs you need to balance if you want to succeed
- mikekchar 11y ago
  I often tell my management, "If it doesn't need to work, I can get it to you any time you want." Everything other than that is a cost/benefit analysis. To be honest, it's hard enough writing a reasonable sized program and not ending up with a horrid mess when I'm doing my best. I'll always recommend giving up functionality over quality if early release is desired. It's easy to add functionality later. It's hard to add quality.

bpchaps 11y ago

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.

mikekchar 11y ago
It is both fortunate and unfortunate that there is a conflict of interest between entrepreneur and architect. As an entrepreneur, your job is to make money. The product is actually secondary. Risk is totally acceptable because you can start 20 companies and as long as 1 of them makes a huge payback, you are in the black. Architects, on the other hand make products. I once was interviewed by a firm that asked me a pointed question about what I did to stop a failed project from failing. My answer was that I gave the best information I could, but that I left it up to the business to decide whether to fail or not. I still think that's the right answer, but it lost me the job. As architects/programmers, we do not succeed by making money. We succeed by writing software. Several times in my career I have been hired to write shells of programs -- demos that will secure funding, knowing that the underlying software was essentially a lie. It just needed to be impressive and potentially disruptive. Probably the company who would shell out for it would cancel it the first chance they got anyway. Is it the type of software I would like to work on? No (though it did pay well ;-) ). In any case, that tension is bound to exist. As long as there is good communication and honesty, the tension can provide good results. One of the first questions I ask in a job interview at a start up is, "Do you intend to make a product?" The second question is, "Do you intend to make the product successful?" The questions about technical debt are only really relevant if the answers to those questions is "yes".
- bpchaps 11y ago
  Honestly, I feel you're making a much larger abstraction than what exists in reality (or maybe what SHOULD exist). Not to say that the abstraction doesn't exist, just that you're a bit too far in the othering-realm for my tastes. There's definitely a middle ground in there where the semantic difference between entrepreneur and architect doesn't exist - where good work and good ideas "are", regardless of how far you swing on that spectrum. I agree that the distinction between the two types of individual is necessary, but an over-use of it is an easy way to lose out in the long run. The question about what you did to stop a failing project is an odd one and probably completely ineffective. If that's the reason they didn't hire you, take it as a good thing. There's too much nuance for it to be considered useful without other considerations. My recent situation was that I pushed too hard to stop a failing project and was socially cast out. By the time the senior staff noticed that my suggestions actually made sense and weren't batshit extreme, the social dynamic was too much and I left. On your last point, I'm not sure that would be a useful question, either. It's so incredibly for a linux lead to say, "Our infrastructure security has no technical debt", for example. It's easy to say, but impossible to prove without being at the company for a while, even for an in-the-mud admin. Hell, that's what happened at the place I just left.

p4wnc6 11y ago

This is a great way of putting it! It's true that many middle managers and business/sales people do not respect this line of reasoning, but that is their mistake rather than a genuine or well thought out business decision -- which is why it bites them in the end. I would take this further and say that it's often a matter of professional disrespect to pay the architect's skepticism such little heed as to override the architect's vote to constrain feature creep. Self-discipline is hard! One of the most challenging aspects of this in real development jobs is that shrewd managers and/or business and sales workers are very good at deflecting blame and creating political situations in which they are able to pretend to have supported the "right" choice no matter what the outcome. So, very often, when features get hacked into the system against the architect's advice and it predictably causes untenable debt growth and parts of the system fall over, what is the first thing you hear? That it is the engineers' fault for not building the system correctly. It's very rare that an architect can successfully communicate the problem of excessive feature growth and convey after a system failure that it was not really the engineers' fault, rather the fault of everyone forcing their poorly conceived features to take priority. In a healthy development environment, everyone should be hearing "no" very, very often when asking to add features, especially when they come to you as if it is a big emergency that some market phenomenon mandates that the feature must be added right now. If you find yourself in an environment where your employer does not empower you, as a developer, to say "no" in that situation definitively, then rather than trying to fight any blame wars about whose fault a system failure was, just get your resume ready and leave. There's no need to put up with that sort of poor engineering culture, and plus, wouldn't you rather put your name on something of quality instead?

jameshart 11y ago

Interesting to place the technical debt creditor/borrower relationship that way round: often it seems that it is seen as being the engineering team who are the debtors, and the debt is owed to some sort of abstract entity - possibly the codebase itself. The developers wind up going to the business and begging for the time to pay down some of the debt, like a college kid going begging to dad to help pay down the credit card after they ran up too much of a bill. I much prefer this characterization, where the engineering team are the lender, and they can call the business in to confront them with the unpaid bills that are coming due and demand a structured plan for how they're going to clear down some of their debt.

chrisabrams 11y ago

What happens when the architect doesn't have the luxury of pushing back? As in, the business will make the architect's boss bend over if the architect says no?

mikekchar 11y ago
Ed Yourdan summed it up very well in one of his books. I don't actually remember which one, so I will try to summarize it, but the quote is worth looking up. If you think that the project you are going to work on will fail; if you think that the work you are doing is crap; vote with your feet. Your time is precious to you. You only have so many years in industry to work on interesting projects. Don't waste them. But there are times when the situation is not perfect, but you still don't want to leave. These can be good times as well. If the project has little or no chance of success, why not experiment with some unconventional techniques? It could be your last chance to do something like that. Working in a group which is failure tolerant can be liberating as well. Finally, make sure that you fully understand the business decisions before you go overboard. In the very first start up I worked in, the management pushed estimates that were wildly inaccurate. We'd say that it would take 4 months and they would promise 1 month to the customer. We failed every single time. When we finally got to a product launch, many years late, I asked the CEO if he wouldn't have rather known at the beginning how long it would take. He smiled and replied, "No, of course not. I would never have gotten funding if I told people that it would take this long." There are things that we, as programmers, know very well. There are things that we do very well. This is also true of business people. Sometimes we, as programmers, can't understand what they are doing because we aren't business people. Sometimes in our hubris, we think we know better than them. Knowing who to trust in these kinds of situations takes time and experience.
- cageface 11y ago
  Deliberately misrepresenting the amount of work it will take to build something is unethical and perhaps even fraudulent. I hate to see people do this kind of thing because it gives our industry a bad rap and could eventually lead to cumbersome regulation or certification. It's true that software budget estimations are by their nature educated guesses at best. But we should still make an effort to be honest about them.

dreamfactory2 11y ago

I don't disagree with the gist of your comment but time to market is generally massively undervalued (and particularly by technical folk). It's more often than not a great reason for taking on tech debt (not to mention that early releases also constrain scope to smaller chunks).

lumpypua 11y ago
I totally agree that time to market is hugely important. The dynamics of getting to market are complicated and I don't agree that tech folk undermine them to any special degree. If you're an engineer with a few years experience, chances are you've been smacked by being too conservative or too loose with tech debt. Good contextual use of debt is a key part of the "senior" in any senior engineer. I'm happy to be "sloppy" and fast at the right moments. My experience has been that business people value time to market, but only if they can offload the costs to engineering by taking on tech debt. When asked to put their money where their mouth is and pay for more engineers or cut scope, often the business side will balk. It's an annoyance when non-technical leadership perennially sees tech debt as a way to get a free lunch. Ain't no free lunches.
deleted 11y ago
[deleted]

deleted 11y ago

[deleted]