3 ms·

Small, but not insurmountable. The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at

Small, but not insurmountable. The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. I’ve yet to find a way to build a moat that withstands that level of hostility without actively harming the organization in the process. I’d love to hear how others deal with this inevitability.

pmarreck 2y ago
if you've built up respect at the company and speak your mind regarding the maintenance vulnerability, the new crew should pay attention. if they don't, then you're screwed anyway, but so is the company. source: endured this while working at a startup that was bought out by SFDC. Kept my principles, but lost the job. /shrug
- stego-tech 2y ago
  Yup, you and Shermantanktop get what I was asking perfectly. Seeking confirmation I hadn’t overlooked anything that I could’ve done better, but you’re both dead-on. The irony is that for those of us who enjoy maintaining, improving, and eventually replacing legacy stuff (code, systems, infrastructure, etc), what we really want is often just stability in career - hence the moat. It means it’s cheaper to keep us around for the long haul than rehiring us again at current market rates every few years, especially if we’re making ends meet with a high quality of life. But that’d mean focusing on the long term, which I don’t see many companies doing in general.
literalAardvark 2y ago
When you're on a reasonably large legacy project that's a pipe dream. One of the old specialty C ERPs I've worked on has literally buried more than 3 (the ones I know of) "great Ruby rewrites". There are just _so many_ features, that the newcomers always ended up on the chopping block after 5-10 years and before they could achieve real customer traction. The old project just ended up getting some more interface fixes instead (aka even more features to catch up to) and to this day the compiler for the core hasn't even been upgraded to a version that can run on anything newer than XP SP1 (the improvements in SP2 break it). Now they're doing another modernization project with some web services and stuff. We're happy to take their money for those as well. I'd be quite shocked if those do anything other than enlarge the moat of the core.
- bornfreddy 2y ago
  Yep. The only possible way to rewrite such projects is to do it gradually, piece by piece. It is also important that the refresh happens from within and is led by those who understand the legacy codebase and, especially, the business requirements it fulfills. No way can an external team do something like that. Being given project description "it must do everything the legacy project does, plus these new features" doesn't help either. If you get a ticket like that - run.
  - Aeolun 2y ago
    I just spent 5 years of my life building such a system. Then we were asked to do it again (a refresh of the refresh, if you will) and everyone marvels that suddenly we can do everything both fast and correct. Well, we just spend 5 years training the team on how to build the old refresh, and now the new refresh can be done properly.
deleted 2y ago
[deleted]
jonahx 2y ago
> The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. The "on borrowed time" is an odd conclusion. When someone takes over, it's typically a priority change ("We want everyone working on new projects, just freeze this old stuff") rather than some kind revenge path against anyone who worked successfully on the old stuff when it was a priority. And a good engineer who is able to handle legacy code will typically be even better when working with greenfield code, because the latter is easier, all else equal. So unless you are refusing the priority change, why would you be on borrowed time?
- shermantanktop 2y ago
  It does happen that the new leader ends up saying out loud "everything we have is terrible," which is easily taken as "everyone who worked on it is terrible." And to be fair, sometimes that's true. And sometimes it's not true but the leader wants to bring over their crew of loyalists and needs to make room somehow. Long-term ownership and careerist jockeying don't go well together.
  - jonahx 2y ago
    Ah, that's definitely true. But that feels like an orthogonal concern to you being an existing dev working on legacy stuff vs greenfield stuff... unless the new boss likes the greenfield stuff for some reason. What you are talking about is more of an ever-present possibility of "new management fallout" in almost any field.
  - mianos 2y ago
    My recent experience is that a lot of the system was not as good as it could have been because it's a hard problem. The company got bought out and all the new bosses come in and say all the existing code and way things are done is crap. Then, a year later, with everyone sacked and new people brought in, once again, these guys say the same thing and promise they are the top guns to fix it all up. I just checked out on the third round.

pmarreck 2y ago

if you've built up respect at the company and speak your mind regarding the maintenance vulnerability, the new crew should pay attention. if they don't, then you're screwed anyway, but so is the company. source: endured this while working at a startup that was bought out by SFDC. Kept my principles, but lost the job. /shrug

stego-tech 2y ago
Yup, you and Shermantanktop get what I was asking perfectly. Seeking confirmation I hadn’t overlooked anything that I could’ve done better, but you’re both dead-on. The irony is that for those of us who enjoy maintaining, improving, and eventually replacing legacy stuff (code, systems, infrastructure, etc), what we really want is often just stability in career - hence the moat. It means it’s cheaper to keep us around for the long haul than rehiring us again at current market rates every few years, especially if we’re making ends meet with a high quality of life. But that’d mean focusing on the long term, which I don’t see many companies doing in general.

literalAardvark 2y ago

When you're on a reasonably large legacy project that's a pipe dream. One of the old specialty C ERPs I've worked on has literally buried more than 3 (the ones I know of) "great Ruby rewrites". There are just _so many_ features, that the newcomers always ended up on the chopping block after 5-10 years and before they could achieve real customer traction. The old project just ended up getting some more interface fixes instead (aka even more features to catch up to) and to this day the compiler for the core hasn't even been upgraded to a version that can run on anything newer than XP SP1 (the improvements in SP2 break it). Now they're doing another modernization project with some web services and stuff. We're happy to take their money for those as well. I'd be quite shocked if those do anything other than enlarge the moat of the core.

bornfreddy 2y ago
Yep. The only possible way to rewrite such projects is to do it gradually, piece by piece. It is also important that the refresh happens from within and is led by those who understand the legacy codebase and, especially, the business requirements it fulfills. No way can an external team do something like that. Being given project description "it must do everything the legacy project does, plus these new features" doesn't help either. If you get a ticket like that - run.
- Aeolun 2y ago
  I just spent 5 years of my life building such a system. Then we were asked to do it again (a refresh of the refresh, if you will) and everyone marvels that suddenly we can do everything both fast and correct. Well, we just spend 5 years training the team on how to build the old refresh, and now the new refresh can be done properly.

deleted 2y ago

[deleted]

jonahx 2y ago

> The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. The "on borrowed time" is an odd conclusion. When someone takes over, it's typically a priority change ("We want everyone working on new projects, just freeze this old stuff") rather than some kind revenge path against anyone who worked successfully on the old stuff when it was a priority. And a good engineer who is able to handle legacy code will typically be even better when working with greenfield code, because the latter is easier, all else equal. So unless you are refusing the priority change, why would you be on borrowed time?

shermantanktop 2y ago
It does happen that the new leader ends up saying out loud "everything we have is terrible," which is easily taken as "everyone who worked on it is terrible." And to be fair, sometimes that's true. And sometimes it's not true but the leader wants to bring over their crew of loyalists and needs to make room somehow. Long-term ownership and careerist jockeying don't go well together.
- jonahx 2y ago
  Ah, that's definitely true. But that feels like an orthogonal concern to you being an existing dev working on legacy stuff vs greenfield stuff... unless the new boss likes the greenfield stuff for some reason. What you are talking about is more of an ever-present possibility of "new management fallout" in almost any field.
- mianos 2y ago
  My recent experience is that a lot of the system was not as good as it could have been because it's a hard problem. The company got bought out and all the new bosses come in and say all the existing code and way things are done is crap. Then, a year later, with everyone sacked and new people brought in, once again, these guys say the same thing and promise they are the top guns to fix it all up. I just checked out on the third round.