This strikes me as dangerous. Didn't the experts build the first system? Don't you want to deliver a fresher system? Won't the experts be attached to the old way of doing things?
> Didn't the experts build the first system? Don't you want to deliver a fresher system? Won't the experts be attached to the old way of doing things?
With all respect, that means you should not be in a position to rewrite legacy code, or to commit others to such a rewrite.
If all the experts you have worked with have been, in your eyes, overly attached to the old way of doing things, you have one of two issues:
- You have not had enough experience in the field, and have not worked with experts that actually have perspective about when/how to rewrite, abandon, or rework their code.
- You have dogmatically condemned people who think that the latest-and-greatest tech may not be a good solution to the problems at hand to the "old fogey" bin.
Either issue means you're not ready to make decisions at this level. Learn more. Research more. Watch more. Listen more.
Weirdly, gaining this perspective has less to do (in my experience) with years on the job, and more with diversity of team/business environments worked in.
Keep in mind that you will be one of these people in a few years for whatever you are doing now. The previous people most likely weren't dummies but had to deal with the technology and constraints at the time they built the system in the same way you are doing it now.
No necessarily. It depends on what has lead to the need for a rebuild. Sometimes there weren't previously the resources to "do things properly", Sometimes a feature might only added for a specific client, etc.
You need that previous knowledge to know the "why" of things & if that why is still valid.
IMHO it's more dangerous if you're working with experts who don't want to improve the system.
