Who should learn the "old" system?_问答_开发者

I've been involved in several projects which basically involved replacing an "old" system with a "new" system. Invariably, the pattern has been that practically no one on the team building the "new" system has any real knowledge of the "old" system. Whenever I questioned this, I've been told that this is purposeful... by not knowing the "old" system, the team is able to think differently and not be limited by how things were done there. So what happens is there is usually only 1 or 2 people on the team that know anything about the "old" system and they are consulted whenever a question comes up about how the "old" system did something.

But what always seems to happen is that after the "new" system is delivered, there are always questions from the user of the form "How do we do X (which was easy in the old system) in the new system开发者_JAVA百科?" For the developers, this is often the first time they have heard of X. So they have to go and research what X is and often the answer they give back to the users is "you can't" or "you can, but it's really awkward".

This does not seem right to me... it seems to me that a lot would be gained by having every developer of the "new" system know the "old" system really well, and that wouldn't necessarily kill their creativity, if they have decent design and development skills.

Any thoughts on which approach is best?

You need better Business Analysts. They are the ones who are supposed to review the old system, and define exactly (and completely) what the new system needs to do. They should provide a full list of requirements for you so that everything that needs to happen has been considered.

Whoever is writing the requirements needs to be more thorough. If that isn't possible, then you may need to get involved and learn the 'old system'.

However there will always be things missed - that's just human nature. You should obviously be trying to make the 'new system' as flexible as you can, so that need features can be added when the users realise they have been forgotten.

I understand your pain.

Replacing an old system with a new one generally implies iso-functionality (i.e the ability to do at least what the old system was able to do)

So, while an in-depth knowledge of the old system is not mandatory, knowing the interfaces and build a set of functional test suites is useful to develop efficiently the new system.
That suite will be used for validating the results of the new development, keeping in mind that the result must never be 100% (otherwise, you would have successfully reproduced the bugs of the first system!)

Plus, for a really large system, you need at least three implementations for your new program:

one able to dialog with the old system
one replacing parts of the old one
one completely taking over the old program

If we are talking about a large period of time, that involves also an Architect able to manage the evolution of the old system (which cannot stand still, waiting several months or years before the new one replaces it), keeping those evolutions in the same direction than your new implementation.

This sounds like the specification for the new system was incomplete because someone (the project manager, the project initiator) didn't ensure that the functionality of the old system was documented and checked to see what the customer actually used.

If this is done then it shouldn't matter that no one knows the old system as the specification is the thing you're developing against.

If you don't have a specification, apart from all the other problems you'll have, everyone should know the old system to avoid this very problem.