4 ms·

> Working only with Good code is a luxury decision, > on an obscene contract rate. Alternate take- being a contractor who gets to roll off the project in 3 mo

> Working only with Good code is a luxury decision, > on an obscene contract rate. Alternate take- being a contractor who gets to roll off the project in 3 months and therefore doesn't have to support the code they write is also a luxury. Those of us who are in-house, on the other hand, do have to support the code we write. And writing Code That Sucks is a great way to burden our colleagues and our future selves with technical debt that is expensive to pay down, if it even gets prioritized in the roadmap at all.

tomlockwood 4y ago
I currently work in-house, and am, today, refactoring other people's tech debt! I don't think some of the code I wrote on that contract will ever be altered again. Pretty sure the VB6 runtime will be impossible to find soon, if it isn't already.
- toomanyrichies 4y ago
  I think I measure tech debt by how easy or hard a piece of code is to change, in response to changing requirements. So yes, I’d agree that if code is never going to be changed again, then the concept of tech debt is less-applicable. That said, predicting which code will or won’t be changed in the future is a difficult prognostication. It seems safer to assume it will be changed on a long enough time span. Then if it’s not, you can be pleasantly surprised.
  - JoeAltmaier 4y ago
    I tell people, code architecture is designing in flexibility you will never use. It's a pretty safe bet you won't guess right.
lamontcg 4y ago
I've been in-house and wound up being the last programmer maintaining the massive pile of tech debt. We had ordering issues and couldn't run our tests in parallel due to global state problems. And it wasn't a mistake here or there, it was the accumulation of a decade of issues. I took a few stabs at it, but doing a week or two of work here and there never moved it significantly forwards. The minitest author took a run at fixing a few of the problems and recommended scrapping the tests entirely and doing a full rewrite. There was no way that I had the time to do that (literally, like me). The answer of course was that the company was effectively dead and it was long past time to quit.
- toomanyrichies 4y ago
  > And it wasn't a mistake here or there, it was the accumulation of a decade of issues. Nodding my head to this. I feel like this is why it’s so hard to convince certain coworkers to take a hard line on code quality. “The class is already 2000 lines of code long, adding one more method isn’t the end of the world.” No one sets out to turn a 100-LoC class into a God class in one PR. It’s always a “death of a thousand cuts” situation. That’s why we need rules which strike some people as arbitrary or draconian, but which I see as a useful tool to fight backsliding, like these [1]. You have to draw the line somewhere. 1. https://thoughtbot.com/blog/sandi-metz-rules-for-developers https://thoughtbot.com/blog/sandi-metz-rules-for-developers
  - lamontcg 4y ago
    Yes, but what do you do once you have a mess and you're understaffed, and the horse left the barn a long time ago?
    - craigmcnamara 4y ago
      You clean it up. I've cleaned up projects that we're total shit shows and the cleanup paid dividends when the time came to update or change that part of the code. Even if a project has gone to seed, things rapidly get better when you start to do things the right way again.
      - lamontcg 4y ago
        Yes, I started to clean it up. If I had stayed there for another 10 years, I might have finished.
    - toomanyrichies 4y ago
      That’s when engineering management needs to make some tough choices, like “No new features on the roadmap until we get our house in order and pay down the tech debt”. Give the staff who are there the time they need to plug the holes in the ship. And if engineering management doesn’t have a seat at the table, i.e. if product or sales or the C-suite looks at engineering as a bunch of order-takers, maybe that company isn’t meant to be long for this world and it’s time to start polishing our CVs. I’m an engineer, not a miracle-worker. My help isn’t for people who need it, it’s for people who want it.

tomlockwood 4y ago

I currently work in-house, and am, today, refactoring other people's tech debt! I don't think some of the code I wrote on that contract will ever be altered again. Pretty sure the VB6 runtime will be impossible to find soon, if it isn't already.

toomanyrichies 4y ago
I think I measure tech debt by how easy or hard a piece of code is to change, in response to changing requirements. So yes, I’d agree that if code is never going to be changed again, then the concept of tech debt is less-applicable. That said, predicting which code will or won’t be changed in the future is a difficult prognostication. It seems safer to assume it will be changed on a long enough time span. Then if it’s not, you can be pleasantly surprised.
- JoeAltmaier 4y ago
  I tell people, code architecture is designing in flexibility you will never use. It's a pretty safe bet you won't guess right.

lamontcg 4y ago

I've been in-house and wound up being the last programmer maintaining the massive pile of tech debt. We had ordering issues and couldn't run our tests in parallel due to global state problems. And it wasn't a mistake here or there, it was the accumulation of a decade of issues. I took a few stabs at it, but doing a week or two of work here and there never moved it significantly forwards. The minitest author took a run at fixing a few of the problems and recommended scrapping the tests entirely and doing a full rewrite. There was no way that I had the time to do that (literally, like me). The answer of course was that the company was effectively dead and it was long past time to quit.

toomanyrichies 4y ago
> And it wasn't a mistake here or there, it was the accumulation of a decade of issues. Nodding my head to this. I feel like this is why it’s so hard to convince certain coworkers to take a hard line on code quality. “The class is already 2000 lines of code long, adding one more method isn’t the end of the world.” No one sets out to turn a 100-LoC class into a God class in one PR. It’s always a “death of a thousand cuts” situation. That’s why we need rules which strike some people as arbitrary or draconian, but which I see as a useful tool to fight backsliding, like these [1]. You have to draw the line somewhere. 1. https://thoughtbot.com/blog/sandi-metz-rules-for-developers https://thoughtbot.com/blog/sandi-metz-rules-for-developers
- lamontcg 4y ago
  Yes, but what do you do once you have a mess and you're understaffed, and the horse left the barn a long time ago?
  - craigmcnamara 4y ago
    You clean it up. I've cleaned up projects that we're total shit shows and the cleanup paid dividends when the time came to update or change that part of the code. Even if a project has gone to seed, things rapidly get better when you start to do things the right way again.
    - lamontcg 4y ago
      Yes, I started to clean it up. If I had stayed there for another 10 years, I might have finished.
  - toomanyrichies 4y ago
    That’s when engineering management needs to make some tough choices, like “No new features on the roadmap until we get our house in order and pay down the tech debt”. Give the staff who are there the time they need to plug the holes in the ship. And if engineering management doesn’t have a seat at the table, i.e. if product or sales or the C-suite looks at engineering as a bunch of order-takers, maybe that company isn’t meant to be long for this world and it’s time to start polishing our CVs. I’m an engineer, not a miracle-worker. My help isn’t for people who need it, it’s for people who want it.