4 ms·

I like to phrase it as acknowledged technical debt. And I think about it like this: when you buy a house, you don't use cash. You borrow. Debt is good as long a

I like to phrase it as acknowledged technical debt. And I think about it like this: when you buy a house, you don't use cash. You borrow. Debt is good as long as you pay it off, and don't get smothered in accumulated interest. Similarly, when you're starting to prototype a complex system with limited time and people resources, it's better to put in working kludges than to attempt a "really good job" on every single component. It's like "perfect is the enemy of good", but crappier. More like "good is the enemy of meh-it'll-do". The difference between a rough prototype and a minefield is that with the former, you record technical debt in the ledger You regularly pay it off, and watch out for interest (kludges on top of kludges, bad architectural decisions because of forced workarounds, or actual financial cost due to inefficiencies).

Zhyl 6y ago
A picture paints a thousand words, but a working prototype is worth a thousand concept pitch decks.
kqr 6y ago
There's a very interesting parallel to your technical debt, and an implicit choice you're not making explicit: One can instead opt to accrue feature debt. Instead of "finishing" the complex system with meh-it'll-do quality, maybe one should focus on finishing the quality even if that only results in a meh-it'll-do system. Sure, the system will be underfeatured to begin with. But it'll be high-performing, rock-solid reliable, easy to work with, quick to iterate on. So by time, you can start paying off the feature debt and add more and more things to create the complex system you're going for in the end. I'd even argue that paying off feature debt taken out on a simple system is much cheaper than trying to pay off technical debt on a complicated system. (This is the premise of "worse-is-better" software development.)
- sammorrowdrums 6y ago
  I think that it also depends on funding, for example: - you have great seed funding and decent runway, you can afford not to have all the required features to make the product viable for longer z and can do a better job. - your potential investors want to see AI being used in your stack before they close on a funding round, so you cludge a basic autoML model or basic tensorflow network and put it somewhere it won't break stuff and scream "we're using AI". Then actually do it when it makes sense properly later. - you need a massive client to show board you're capable of revenue, they demand a feature in order to close, so you build it ASAP. I think what I'm trying to say is the lean startup art is to carefully leverage technical debt and feature debt in the appropriate times, and have a culture of cleaning little bits as you work o other features. Having a good eye for architecture and clean code is the secret sauce. As long as there are people reviewing code who understand this, you'll hopefully end up with isolated technical debt, which can be kept under control and won't sink your startup when you expand and accelerate growth.
  - snarfy 6y ago
    This is a really great example that I wish more engineers understood. There are an enormous amount of external factors that play into why that software project must have features a, b, and c and must be done by next friday. Good code costs time and money which are luxuries you don't always have.
foolmeonce 6y ago
> You borrow. Debt is good as long as you pay it off I think this is where software and other sectors come together to demonstrate why something that seems good ends up evil. What is to stop someone from borrowing slightly further beyond their means than you? What does that mean for the market? Housing is unaffordable, turning us into slaves and also in a wired crisis, software is either free, vaporware or impossible to discover under all the vapourware and the website needed to compete with vaporware.. Without standards, ratings, limits, strong unions and trade associations, everything becomes a market for lemons since someone will take the risk of faking it all when the penalties are only partial revocation of the profits.
- galoisgirl 6y ago
  > What is to stop someone from borrowing slightly further beyond their means than you? In Europe, banking laws.
- specialist 6y ago
  Nice. "everything becomes a market for lemons..." Long I've been pondering how our notions of technical debt (managing risk, complexity) might apply to government, regulations, bureaucracy, etc. There's so many analogs. eg René Descartes said our cities would be simple and orderly if designed by a single mind. Now your comment makes me realize I ignored the flip. What are our analogs (in software, design) to regulatory capture, rent seeking, and other pathologies. Thank you.
  - dredmorbius 6y ago
    Cities designed by a single mind are often simple, orderly, ... and dysfunctional. Evolution over time, successfully addressing challenges, accumulating wisdom, avoiding classic blunders, works pretty well.
- sokoloff 6y ago
  > What is to stop someone from borrowing slightly further beyond their means than you? There's always a spectrum of risk-taking. Some people will borrow every last dollar their bank will let them. Others will not. I was shocked at the size of the loan that the bank pre-approved me for back in 2007 (fairly crazy times in US housing market). I borrowed substantially less than that because I wasn't comfortable taking out a loan at that high of a debt-to-income ratio. On the flip-side, had I taken out a maximum-sized loan, I'd have made more paper gains in housing in the last 13 years, so there is often reward for risk-taking.
ilaksh 6y ago
If it was just based on the title and the term "half-assed" then I would agree about technical debt. But having read the article, I'm not sure that is quite what he was saying. He is talking about prioritization of effort and how thorough the solutions are. If you properly judge the importance of things or the level of sophistication actually needed to solve the problem adequately (but not necessarily "fully"), you may not ever need to revisit that part. Especially since requirements evolve. But also because bottlenecks (in terms of performance or requirements churn or bugs etc.) are often clustered in particular areas. So even though there is a more complicated solution that could be more elegant or flexible or performant, it may actually never make sense to implement because the relative importance just never increases. What he seems to be more or less talking about is similar to the 80/20 Rule (ala Pareto Principle). I think a less negative term could have been less confusing.
deleted 6y ago
[deleted]
tehlike 6y ago
The good thing with technical debt is inflation in some way. The code will likely get rewritten every few years with new features in mind, or will change significantly anyway so it's almost as if it's inflation. If technical debt allows you to get great gains in short time through product (just like any useful debt), technical debt is warranted. I spent 6.5 years in google and seen an sdk get rewritten 2 times, 3rd was about to happen after I left but product director asked me if it was warranted, I said it sounds more like all these problems you are mentioning are monitoring/detection/testing problems and rewriting it won't make sense. The code did have technical debt, but it didn't matter

Zhyl 6y ago

A picture paints a thousand words, but a working prototype is worth a thousand concept pitch decks.

kqr 6y ago

There's a very interesting parallel to your technical debt, and an implicit choice you're not making explicit: One can instead opt to accrue feature debt. Instead of "finishing" the complex system with meh-it'll-do quality, maybe one should focus on finishing the quality even if that only results in a meh-it'll-do system. Sure, the system will be underfeatured to begin with. But it'll be high-performing, rock-solid reliable, easy to work with, quick to iterate on. So by time, you can start paying off the feature debt and add more and more things to create the complex system you're going for in the end. I'd even argue that paying off feature debt taken out on a simple system is much cheaper than trying to pay off technical debt on a complicated system. (This is the premise of "worse-is-better" software development.)

sammorrowdrums 6y ago
I think that it also depends on funding, for example: - you have great seed funding and decent runway, you can afford not to have all the required features to make the product viable for longer z and can do a better job. - your potential investors want to see AI being used in your stack before they close on a funding round, so you cludge a basic autoML model or basic tensorflow network and put it somewhere it won't break stuff and scream "we're using AI". Then actually do it when it makes sense properly later. - you need a massive client to show board you're capable of revenue, they demand a feature in order to close, so you build it ASAP. I think what I'm trying to say is the lean startup art is to carefully leverage technical debt and feature debt in the appropriate times, and have a culture of cleaning little bits as you work o other features. Having a good eye for architecture and clean code is the secret sauce. As long as there are people reviewing code who understand this, you'll hopefully end up with isolated technical debt, which can be kept under control and won't sink your startup when you expand and accelerate growth.
- snarfy 6y ago
  This is a really great example that I wish more engineers understood. There are an enormous amount of external factors that play into why that software project must have features a, b, and c and must be done by next friday. Good code costs time and money which are luxuries you don't always have.

foolmeonce 6y ago

> You borrow. Debt is good as long as you pay it off I think this is where software and other sectors come together to demonstrate why something that seems good ends up evil. What is to stop someone from borrowing slightly further beyond their means than you? What does that mean for the market? Housing is unaffordable, turning us into slaves and also in a wired crisis, software is either free, vaporware or impossible to discover under all the vapourware and the website needed to compete with vaporware.. Without standards, ratings, limits, strong unions and trade associations, everything becomes a market for lemons since someone will take the risk of faking it all when the penalties are only partial revocation of the profits.

galoisgirl 6y ago
> What is to stop someone from borrowing slightly further beyond their means than you? In Europe, banking laws.
specialist 6y ago
Nice. "everything becomes a market for lemons..." Long I've been pondering how our notions of technical debt (managing risk, complexity) might apply to government, regulations, bureaucracy, etc. There's so many analogs. eg René Descartes said our cities would be simple and orderly if designed by a single mind. Now your comment makes me realize I ignored the flip. What are our analogs (in software, design) to regulatory capture, rent seeking, and other pathologies. Thank you.
- dredmorbius 6y ago
  Cities designed by a single mind are often simple, orderly, ... and dysfunctional. Evolution over time, successfully addressing challenges, accumulating wisdom, avoiding classic blunders, works pretty well.
sokoloff 6y ago
> What is to stop someone from borrowing slightly further beyond their means than you? There's always a spectrum of risk-taking. Some people will borrow every last dollar their bank will let them. Others will not. I was shocked at the size of the loan that the bank pre-approved me for back in 2007 (fairly crazy times in US housing market). I borrowed substantially less than that because I wasn't comfortable taking out a loan at that high of a debt-to-income ratio. On the flip-side, had I taken out a maximum-sized loan, I'd have made more paper gains in housing in the last 13 years, so there is often reward for risk-taking.

ilaksh 6y ago

If it was just based on the title and the term "half-assed" then I would agree about technical debt. But having read the article, I'm not sure that is quite what he was saying. He is talking about prioritization of effort and how thorough the solutions are. If you properly judge the importance of things or the level of sophistication actually needed to solve the problem adequately (but not necessarily "fully"), you may not ever need to revisit that part. Especially since requirements evolve. But also because bottlenecks (in terms of performance or requirements churn or bugs etc.) are often clustered in particular areas. So even though there is a more complicated solution that could be more elegant or flexible or performant, it may actually never make sense to implement because the relative importance just never increases. What he seems to be more or less talking about is similar to the 80/20 Rule (ala Pareto Principle). I think a less negative term could have been less confusing.

deleted 6y ago

[deleted]

tehlike 6y ago

The good thing with technical debt is inflation in some way. The code will likely get rewritten every few years with new features in mind, or will change significantly anyway so it's almost as if it's inflation. If technical debt allows you to get great gains in short time through product (just like any useful debt), technical debt is warranted. I spent 6.5 years in google and seen an sdk get rewritten 2 times, 3rd was about to happen after I left but product director asked me if it was warranted, I said it sounds more like all these problems you are mentioning are monitoring/detection/testing problems and rewriting it won't make sense. The code did have technical debt, but it didn't matter