2 ms·

I'm currently working at a company that is facing this problem. The programming team has stagnated on repairing legacy systems. Innovation and modernization i

by ambiate 14y ago

I'm currently working at a company that is facing this problem. The programming team has stagnated on repairing legacy systems. Innovation and modernization is a business objective, but the philosophical issue of losing 'expert business knowledge' due to technological evolution presents barriers in the process. Our code ranges from 10 to 20 years old. Most of the principles involved in that based are from those years too. Moving to any framework, language or SOA means training 16 people for years. Not because the language, framework, or services are too hard to grasp, but because the overall arching backbone is missing. We haven't reached 3-layered programming, let's jump straight into 5-layered. We're still in waterfall functional code with weak modularization and few OOP principles. Yet, we're trying to skip the whole OOP/modularization schematic and jump right into fully decoupled SOA. Without understanding the hardships of the middle, I find it difficult to believe we can transition to the end without losing half of our team.

peterbell_nyc 14y ago
Yeah - that's a really hard change. For anyone dealing with a legacy system, I always recommend Mike Feathers' book on "working effectively with legacy code". He talks about lots of patterns for dealing with this. I'd probably see if I could start to break off a piece of a system, bring in a consultant or new dev for a couple of months, pair them with one of your team and rotate every few weeks. You won't lose too much capacity in terms of working on the core system and you'll get a chance to start to slowly introduce members of your team to new best practices. Sometimes single page web apps can help with some of this as you can just drop in backbone on a page or two and use it to federate data from both your main app and a new app you're adding some functionality to. You probably will end up losing half the team over time, but honestly if they put up with the current state of affairs for so long, that might not end up being a bad long term outcome. Just don't big bang any changes - cultural or technical. And try to ignite curiosity rather than "mandating innovation"
- ambiate 14y ago
  Thank you for the advice and reference. It is difficult to find actual advice in these circumstances other than 'consult consult consult.' That last line really shifted my outlook on this experience.
RougeFemme 14y ago
Testers feel that pain, too. (Not talking about dev/testers but dedicated testers and white-box ones, in particular). Testers get bored when they're testing repeatedly testing something which does not change at all technologically. And since the productivity is usually lower with the legacy technologies, testers can't even count on many new features in each release. Yes, testers get jealous, too.

by ambiate 14y ago

peterbell_nyc 14y ago

Yeah - that's a really hard change. For anyone dealing with a legacy system, I always recommend Mike Feathers' book on "working effectively with legacy code". He talks about lots of patterns for dealing with this. I'd probably see if I could start to break off a piece of a system, bring in a consultant or new dev for a couple of months, pair them with one of your team and rotate every few weeks. You won't lose too much capacity in terms of working on the core system and you'll get a chance to start to slowly introduce members of your team to new best practices. Sometimes single page web apps can help with some of this as you can just drop in backbone on a page or two and use it to federate data from both your main app and a new app you're adding some functionality to. You probably will end up losing half the team over time, but honestly if they put up with the current state of affairs for so long, that might not end up being a bad long term outcome. Just don't big bang any changes - cultural or technical. And try to ignite curiosity rather than "mandating innovation"

ambiate 14y ago
Thank you for the advice and reference. It is difficult to find actual advice in these circumstances other than 'consult consult consult.' That last line really shifted my outlook on this experience.

RougeFemme 14y ago

Testers feel that pain, too. (Not talking about dev/testers but dedicated testers and white-box ones, in particular). Testers get bored when they're testing repeatedly testing something which does not change at all technologically. And since the productivity is usually lower with the legacy technologies, testers can't even count on many new features in each release. Yes, testers get jealous, too.