4 ms·

It is maddening. Even if the stated goal is to “get off the mainframe” everybody deep down knows it isn’t going anywhere for 10 years. We recently had a discuss

It is maddening. Even if the stated goal is to “get off the mainframe” everybody deep down knows it isn’t going anywhere for 10 years. We recently had a discussion about porting from one mainframe “module” to another due to cost. I asked why we don’t just continue paying for the current module since the goal is to sunset mainframe. Everybody on the call laughed. So we will go ahead and “invest” several man years and god knows how much money into a platform everybody agrees we should get off of.

tdeck 5y ago
I've been on the other side of this and seen too many teams neglect to fix even the simplest and most frustrating bugs in a system because they're going to rewrite it "in the next six months". Usually the rewrite is still going years later, and the actual code used in production is left to rot, holding back other teams as well.
- wyldfire 5y ago
  Can you blame them? These are the same teams who typically refuse to adopt practices that would allow them to create tests and we'll encapsulated designs. So inevitably the team is once bitten twice shy about breaking production. Why be the poor bastard who introduced anything but the tiniest bugfix?
  - tdeck 5y ago
    I definitely agree it's a matter of incentives. Even in an environment with a now healthier quality culture, fixing bugs to bring an old system from 70% functionality to 100% is typically a career dead end. It's much better to leave it broken and build a new system with 105% functionality so you can take credit for the whole 105%. And typically, optimists that we are, it seems like completely reimplementing the original functionality will be "trivial" compared to merely trying to understand how the existing solution works.
- trixie_ 5y ago
  It happens when you have a lot of new people who refuse to work with legacy code (which is anything over 2 years old), trivialize the complexity of the existing system (because they don’t understand a tenth of what it does), go create a sub par replacement with tons of people and years of work (that ends up coupled to the legacy system anyways), and now the company has two systems to maintain requiring double the resources as before. When everyone gets fed up and leaves, the cycle will start again. Our system is about four levels deep now. It’s the f’ing matrix.
  - nikau 5y ago
    Most of the new development I've worked on has been terrible, I attribute it to agile and the two week sprints churning out non stop MVP code that's technical debt from day one.

tdeck 5y ago

I've been on the other side of this and seen too many teams neglect to fix even the simplest and most frustrating bugs in a system because they're going to rewrite it "in the next six months". Usually the rewrite is still going years later, and the actual code used in production is left to rot, holding back other teams as well.

wyldfire 5y ago
Can you blame them? These are the same teams who typically refuse to adopt practices that would allow them to create tests and we'll encapsulated designs. So inevitably the team is once bitten twice shy about breaking production. Why be the poor bastard who introduced anything but the tiniest bugfix?
- tdeck 5y ago
  I definitely agree it's a matter of incentives. Even in an environment with a now healthier quality culture, fixing bugs to bring an old system from 70% functionality to 100% is typically a career dead end. It's much better to leave it broken and build a new system with 105% functionality so you can take credit for the whole 105%. And typically, optimists that we are, it seems like completely reimplementing the original functionality will be "trivial" compared to merely trying to understand how the existing solution works.
trixie_ 5y ago
It happens when you have a lot of new people who refuse to work with legacy code (which is anything over 2 years old), trivialize the complexity of the existing system (because they don’t understand a tenth of what it does), go create a sub par replacement with tons of people and years of work (that ends up coupled to the legacy system anyways), and now the company has two systems to maintain requiring double the resources as before. When everyone gets fed up and leaves, the cycle will start again. Our system is about four levels deep now. It’s the f’ing matrix.
- nikau 5y ago
  Most of the new development I've worked on has been terrible, I attribute it to agile and the two week sprints churning out non stop MVP code that's technical debt from day one.