3 ms·

One of the big ah-ha moments I had while reading Start Small, Stay Small by Rob Walling was that most developers have an aversion to carrying technical debt bec

One of the big ah-ha moments I had while reading Start Small, Stay Small by Rob Walling was that most developers have an aversion to carrying technical debt because they've experienced managers that never allow them to pay it back later. But when it's your startup (or small software company), you can choose when to pay back technical debt. It sounds obvious, but I hadn't thought of it that way. Once I realized I had full control of when to pay back tech debt, it made me more comfortable accruing it strategically.

x0x0 6y ago
Hey, I thought I recognized your name! I enjoy your book reviews.
- mtlynch 6y ago
  Oh, cool. Glad that they're useful!
RangerScience 6y ago
Job prior to this one was at a raw stage startup (two cofounders, both new college grad). Most of the back-end code base was written by a now-departed first employee (also a new grad), and it was a trash fire. The "tech" founder had a decent front-end code base, where they were very much doing what you describe: I could tell which parts of the code were written when, based on their skill growth, etc etc. As an employee, it wasn't my call when to pay down the back-end's debt. I was very happy to get out of that. Anyway. Yes, it's different when it's your debt, and what makes it your debt is then whether you're the one who decides when to pay it.
- Kiro 6y ago
  Wasn't the point that as a founder you're more likely to accrue technical debt? Your anecdote sounds like the opposite.
onion2k 6y ago
But when it's your startup (or small software company), you can choose when to pay back technical debt. This is true but you will always feel that paying off the debt isn't growing the business or giving any real benefit to the customer. If you can fight that then it works. If you can't then you'll get more and more technical debt.
- mnahkies 6y ago
  I don't know that this is true for all technical debt. Generally there should be a motivation behind "fixing" technical debt that is expressible in terms of business value, whether that means faster page loads, more uptime, or ability to deliver X,y,z faster (or at all in extreme cases) If you can't express the trade-off of solving the debt in terms of business value then it's going to be low priority by definition. Another strategy for things that as engineers we know will make things better in the long run but show little immediate value can be to ask for a small amount of time per sprint/week to invest - ideally you should still be able to articulate why something is worth changing though
  - rualca 6y ago
    > I don't know that this is true for all technical debt. Even if there might be some exceptions for some technical debt, it's always true from the product owner's and business perspective. Keep in mind that it takes resources, and sometimes even downtime, to address technical debt. In the POV of a product manager, addressing technical debt is an investment with the promise of little short-term returns with the tradeoff of significant risk in the form of downtime and regressions and bugs. And more importantly, technical debt is not a "one and done" deal. There are always more rewrites and refactoring to be done, and the one you're doing today might be the topic of technical debt discussions in the future.
- Fire-Dragon-DoL 6y ago
  Actually recognizing when that statement is false is what pushes you further as a developer. This statement tend to be true when you accumulated so much debt that you cannot fix it anymore, but if you end up there with the premise it's your startup, you failed as the tech lead
avh02 6y ago
first time i had a tech lead and product manager who understood when tech debt needed to be tackled was a huge relief to my previous roles/teams.
danjac 6y ago
The thing is you need to pay back the debt before the management culture coagulates and everything has to be broken down into dozens of Jira tickets each requiring hour-long grooming meetings. You won't have the freedom then to do the root-and-branch refactoring you need to do.

x0x0 6y ago

Hey, I thought I recognized your name! I enjoy your book reviews.

mtlynch 6y ago
Oh, cool. Glad that they're useful!

RangerScience 6y ago

Job prior to this one was at a raw stage startup (two cofounders, both new college grad). Most of the back-end code base was written by a now-departed first employee (also a new grad), and it was a trash fire. The "tech" founder had a decent front-end code base, where they were very much doing what you describe: I could tell which parts of the code were written when, based on their skill growth, etc etc. As an employee, it wasn't my call when to pay down the back-end's debt. I was very happy to get out of that. Anyway. Yes, it's different when it's your debt, and what makes it your debt is then whether you're the one who decides when to pay it.

Kiro 6y ago
Wasn't the point that as a founder you're more likely to accrue technical debt? Your anecdote sounds like the opposite.

onion2k 6y ago

But when it's your startup (or small software company), you can choose when to pay back technical debt. This is true but you will always feel that paying off the debt isn't growing the business or giving any real benefit to the customer. If you can fight that then it works. If you can't then you'll get more and more technical debt.

mnahkies 6y ago
I don't know that this is true for all technical debt. Generally there should be a motivation behind "fixing" technical debt that is expressible in terms of business value, whether that means faster page loads, more uptime, or ability to deliver X,y,z faster (or at all in extreme cases) If you can't express the trade-off of solving the debt in terms of business value then it's going to be low priority by definition. Another strategy for things that as engineers we know will make things better in the long run but show little immediate value can be to ask for a small amount of time per sprint/week to invest - ideally you should still be able to articulate why something is worth changing though
- rualca 6y ago
  > I don't know that this is true for all technical debt. Even if there might be some exceptions for some technical debt, it's always true from the product owner's and business perspective. Keep in mind that it takes resources, and sometimes even downtime, to address technical debt. In the POV of a product manager, addressing technical debt is an investment with the promise of little short-term returns with the tradeoff of significant risk in the form of downtime and regressions and bugs. And more importantly, technical debt is not a "one and done" deal. There are always more rewrites and refactoring to be done, and the one you're doing today might be the topic of technical debt discussions in the future.
Fire-Dragon-DoL 6y ago
Actually recognizing when that statement is false is what pushes you further as a developer. This statement tend to be true when you accumulated so much debt that you cannot fix it anymore, but if you end up there with the premise it's your startup, you failed as the tech lead

avh02 6y ago

first time i had a tech lead and product manager who understood when tech debt needed to be tackled was a huge relief to my previous roles/teams.

danjac 6y ago

The thing is you need to pay back the debt before the management culture coagulates and everything has to be broken down into dozens of Jira tickets each requiring hour-long grooming meetings. You won't have the freedom then to do the root-and-branch refactoring you need to do.