A guide for reducing tech debt effectively, and how to develop a mindset that welcomes the short-term benefits of eliminating it. A guest post by principal engineer Lou Franco
> We’re not excited by incremental renovation: tinkering, improving, planting flower beds.
it's a small thing to focus on but I really dislike this quote and this view. it is not true in my experience that we are all, or even mostly, like this. it is my experience that people who like building something new are given greater recognition and reward for their efforts. the industry is self selecting for this trait, and many others get pushed sideways into other roles including tpm, manager, and sre.
a common way this manifests is a project with two implementation proposals - write it in place with fixes to the whole flow so it's all cohesive, or write it in brand new code in a brand new microservice and database table with an if statement. 9/10 times people in power select the latter - because the estimates are a few weeks shorter, and everyone involved will get a big boost to their next performance review. but within a year those 3 saved weeks are long lost - emergency scaling, edge cases going to the wrong flow, backfills, reimplementing guards that exist in the old flow, implementing the next feature twice, and an increased operational load.
a year later, everyone will agree it was a mistake, but yet still dont listen the next time someone speaks up and says "let's fix what we have to handle it."
if we want people to take a step back and think critically about that big rewrite, you should make sure the people who do it naturally are in the room, sufficiently promoted, and their opinions valued.
Dunvi: I'd just add the context that Joel wrote this in 2000 (during the Dotcom Boom): it was the year he started Fog Creek Software. Just being empathetic, I wonder if back then it was more common to focus on rewriting things with new technology, and thus this thinking dominant, at least in his context?
My two cents is that it's a lot easier to care about craft once you get "bitten" by the lack of it (or the lack of maintenance.)
I agree with people mostly learning from experience!
I cant comment on whether things have changed from 2000, but I see a lot of companies still focus on exactly that - constantly rewriting things to use "new technology". Where that new technology brings insufficient new value, and the rewrites cost value.
thanks for the rec, I enjoyed his essays. one of them reminded me that one big limiter to effective innovation is friction in the process of innovating and creating. tech debt creates that friction, and thoughtfully removing it will magnify all the following innovations. i've seen project estimates drop by an order of magnitude after 4 weeks removing tech debt. that led to a LOT of new proposals.
> it is my experience that people who like building something new are given greater recognition and reward for their efforts.
Totally agreed. I think your comment is very aligned with the ultimate outcome in Joel's article though -- perhaps with the "blame" being on incentives rather than on innate traits. If so, that's a big relief because it points towards something we can do about it.
Definitely agree that metrics like EPM, that in SRE world are often called SLIs (service level indicators) are great way to set expectations and communicate with business stakeholders. Without them it's so easy / tempting to focus on "improvements" that in the end just don't matter, and to miss the important ones.
> We’re not excited by incremental renovation: tinkering, improving, planting flower beds.
it's a small thing to focus on but I really dislike this quote and this view. it is not true in my experience that we are all, or even mostly, like this. it is my experience that people who like building something new are given greater recognition and reward for their efforts. the industry is self selecting for this trait, and many others get pushed sideways into other roles including tpm, manager, and sre.
a common way this manifests is a project with two implementation proposals - write it in place with fixes to the whole flow so it's all cohesive, or write it in brand new code in a brand new microservice and database table with an if statement. 9/10 times people in power select the latter - because the estimates are a few weeks shorter, and everyone involved will get a big boost to their next performance review. but within a year those 3 saved weeks are long lost - emergency scaling, edge cases going to the wrong flow, backfills, reimplementing guards that exist in the old flow, implementing the next feature twice, and an increased operational load.
a year later, everyone will agree it was a mistake, but yet still dont listen the next time someone speaks up and says "let's fix what we have to handle it."
if we want people to take a step back and think critically about that big rewrite, you should make sure the people who do it naturally are in the room, sufficiently promoted, and their opinions valued.
Dunvi: I'd just add the context that Joel wrote this in 2000 (during the Dotcom Boom): it was the year he started Fog Creek Software. Just being empathetic, I wonder if back then it was more common to focus on rewriting things with new technology, and thus this thinking dominant, at least in his context?
My two cents is that it's a lot easier to care about craft once you get "bitten" by the lack of it (or the lack of maintenance.)
I agree with people mostly learning from experience!
I cant comment on whether things have changed from 2000, but I see a lot of companies still focus on exactly that - constantly rewriting things to use "new technology". Where that new technology brings insufficient new value, and the rewrites cost value.
Luiz André Barroso addressed this issue in:
Short Essays on Engineering Culture
Innovate Within: The underappreciated a of non-disruptive innovation
https://fontoura.org/papers/barroso.pdf
thanks for the rec, I enjoyed his essays. one of them reminded me that one big limiter to effective innovation is friction in the process of innovating and creating. tech debt creates that friction, and thoughtfully removing it will magnify all the following innovations. i've seen project estimates drop by an order of magnitude after 4 weeks removing tech debt. that led to a LOT of new proposals.
> it is my experience that people who like building something new are given greater recognition and reward for their efforts.
Totally agreed. I think your comment is very aligned with the ultimate outcome in Joel's article though -- perhaps with the "blame" being on incentives rather than on innate traits. If so, that's a big relief because it points towards something we can do about it.
Very cool article! Totally matches my experience as well.
Definitely agree that metrics like EPM, that in SRE world are often called SLIs (service level indicators) are great way to set expectations and communicate with business stakeholders. Without them it's so easy / tempting to focus on "improvements" that in the end just don't matter, and to miss the important ones.