4 ms·

If you start a rewrite or a large refactor, for Gods sake, follow through and _finish_. Otherwise you have made things even worse. I can't tell you how often I'

If you start a rewrite or a large refactor, for Gods sake, follow through and _finish_. Otherwise you have made things even worse. I can't tell you how often I've come across the remnants of such projects, abandoned with some sliver left. I make a point to never leave it like that.

cratermoon 4y ago
Few places I've worked ever put improving the system in the plan. It's almost always said that "we'll work on it later, when we have time". Later almost never comes, of course. On the rare cases when there is a little time, the team will start something but have to abandon it when inevitably the business needs change and they get drawn to other work. Remnants of incomplete attempts speckle the codebase like bird droppings on a car parked under a tree for 6 months.
- bberrry 4y ago
  I think that's part of our responsibility as engineers to ensure that technical debt doesn't pile up. Business will want to focus on pushing new stuff and engineers have to be a counterbalancing force. It's literally your job. This hasn't been a problem in the places I've worked. Perhaps I'm lucky or it's the fact that I don't live in a very hierarchical society (Sweden).
  - cratermoon 4y ago
    You're correct that it's the engineers need to be responsible, starting with not offering lowball estimates for development and then taking shortcuts and ignoring problems just to get the features out the door. There are plenty of businesses perfectly happy with hiring developers that will ship things as fast as possible over developers that will take responsibility for the code. I've worked both places. Unsurprisingly, I don't stay too long at places where I find myself working with a team full of shortcutters.
- jamesfinlayson 4y ago
  Yes I remember working on a legacy system (PHP application started in 2003) - there were two or three different attempts to make it MVC sprinkled throughout the codebase - obviously a few people had come and decided to improve things (and decided the last guy's work was no good) but left before making any meaningful progress.

cratermoon 4y ago

Few places I've worked ever put improving the system in the plan. It's almost always said that "we'll work on it later, when we have time". Later almost never comes, of course. On the rare cases when there is a little time, the team will start something but have to abandon it when inevitably the business needs change and they get drawn to other work. Remnants of incomplete attempts speckle the codebase like bird droppings on a car parked under a tree for 6 months.

bberrry 4y ago
I think that's part of our responsibility as engineers to ensure that technical debt doesn't pile up. Business will want to focus on pushing new stuff and engineers have to be a counterbalancing force. It's literally your job. This hasn't been a problem in the places I've worked. Perhaps I'm lucky or it's the fact that I don't live in a very hierarchical society (Sweden).
- cratermoon 4y ago
  You're correct that it's the engineers need to be responsible, starting with not offering lowball estimates for development and then taking shortcuts and ignoring problems just to get the features out the door. There are plenty of businesses perfectly happy with hiring developers that will ship things as fast as possible over developers that will take responsibility for the code. I've worked both places. Unsurprisingly, I don't stay too long at places where I find myself working with a team full of shortcutters.
jamesfinlayson 4y ago
Yes I remember working on a legacy system (PHP application started in 2003) - there were two or three different attempts to make it MVC sprinkled throughout the codebase - obviously a few people had come and decided to improve things (and decided the last guy's work was no good) but left before making any meaningful progress.