Migrating features, old app to new app
-
Let's say we have App 1.0, and it was written as a one-off in an unmaintainable fashion. Now let's say that we want to make App 2.0 and bring it up to a more maintainable language and design. The dilemma (internally) is: how to approach this "migration." The features in 1.0 should, for the most part, be in 2.0.
I am wondering whether you think it is better to approach the features from observing the old (and bad) code, or from observing App 1.0 in action and resorting to the code when things are unclear. How about tracking changes as features are implemented? What would the approach be there?
P.S. I've got some strong feelings about this already, but I'm just wondering what the consensus is among developers.
-
In this scenario, I would treat the 1.0 application as a functional spec.
Go ahead and re-write a technical design that encompasses all of the 1.0 features, adding in the new features needed for 2.0 (if any). Don't forget that you must migrate all the DATA from app 1.0 as well. Plan for it.
Projects like this are a golden opportunity to fix the design of things, and keep in mind that you'll not likely be given ANOTHER chance to redesign it.
-
@RaspenJho said:
In this scenario, I would treat the 1.0 application as a functional spec.
Go ahead and re-write a technical design that encompasses all of the 1.0 features, adding in the new features needed for 2.0 (if any). Don't forget that you must migrate all the DATA from app 1.0 as well. Plan for it.
Projects like this are a golden opportunity to fix the design of things, and keep in mind that you'll not likely be given ANOTHER chance to redesign it.
Any deviation from this will result in an App 2.0 that is less than it could be.
approach the features from observing the old (and bad) code
If you do this, what will you have? A copy of App 1.0!
Program by spec. If you're really serious about this, make sure you write a functional spec AND a technical spec as wholly separate documents. They should be, anyway. The functional spec only says "it should do X". The technical spec says "we implement X via a table A with FK-linked table B to be done in script file C using third-party algorithm D."
-
If you ask me (and you did, I guess), in the short term, total rewrites are disasters more often than successes. The new version will certainly not be App 2.0; more like App 0.5. You may get a better design out of it, but you get a bunch of new bugs, too. Plus, you'll find that your new version still has ugly parts to it simply to mimic the original's odd behaviors and corner cases that users have begun to work with (and maybe even rely upon). A better option, if you can manage it, is to continue development on the old application while bringing the new one up to speed behind the scenes. Or identify subsystems and replace them one at a time.
Now that I'm done pontificating, to answer your actual questions: Does the original have a deeply entrenched userbase? Is it mission critical? Because if the answer is no to both, then you can feel free to simply correct the features to erase bad behavior. If the first answer is yes and the second is no, you can fix bad behavior, but be prepared for at least one angry backlash when you break an "undocumented feature". If the answer to both is yes, then follow the old behavior wherever possible, no matter how stupid it seems.
-
word of advice. Don't call your new app 2.0 from 1.0 unless is actually does more or at least looks a lot better. Unless of course you have an awesome marketing team.
-
Why look at the actual app 1.0 at all? Look at the original specs for it, and detailed documentation for every new feature or bug fix. Merge those into a new spec.
Oh, nobody at your company keeps documentation either? Treat each component as a black box and then try to reproduce it. Roll them out one at a time to ensure that backwards compatibility is maintained. Also has the added benefit of keeping around all the broken architectural decisions and component interactions that made it so unmaitainable in the first place. But this time it's in Java, so it's better! Or something.
