|
This is not impressive. This is normal. When they say "What's the hardest thing you've done?" I would hope that if you are going to run with this, you explain why conventional maintenance/upgrades were so extraordinarily difficult in this case. Every developer dreams of going greenfield. Ultimately, that's because it's harder and much more tedious to read code than to write it. If you start from scratch, you understand the whole stack/platform, everything is customized to your liking, and so on. That's great for you, but the company is usually stuck spinning its wheels for months while you push this rewrite down their throats. It's also very easy to underestimate the depth of domain knowledge and accounted-for corner cases encoded in an old codebase. It looks easy at first, but it usually ends up taking at least months to reach feature parity with the old software, which usually also means that people will use both systems simultaneously, requiring data synchronization, etc. The whole thing becomes messy, and by the time you're done, the "new system" usually isn't really all that improved over the old system. Systems get convoluted in the process of development, business needs demand quick shoehorning of something instead of thorough refactoring, etc. Once in a while, a full rewrite is indeed justified, but it's much rarer than most people think. Going in saying "Yes, my company needed a full rewrite" is an instant orange flag in my book, and thorough questioning would be needed to determine if this is an ongoing attitude problem where there's a reluctance/reticence to read other peoples' code. That portends laziness, a disrespect for colleagues, and a disrespect for the business's needs, which are rarely aligned with tying its developer labor up in a greenfield reimplementation. |
We have an outside consultant who does one thing: Fix businesses.
When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it.
While I understand and don't disagree with what you say - a full rewrite is normally not the answer - you haven't seen this codebase. Or the company structure.
We aren't exactly doing a "full rewrite"... it would honestly be easier in many respects - we are keeping the company functional while replacing large chunks.
Aka Keeping the Train Moving while changing the Engine and the Wheels.
This isn't JUST a code base issue. Or JUST a culture. Or JUST management. It's a combination of all those - and many more that can't be covered in 3 paragraphs.
I could talk for 8 hours - and scratch the surface - of where we are and where we need to be.