How to approach migrations?
Friedrich Dominicus
one approach migrations. Or should one avoid them like the plague.
Here's one opinion about it:
http://www.joelonsoftware.com/articles/fog0000000069.html
So, this clearly meant don't do it.
Now what should one do if one has e.g an DBASE III or so project
today? Or what should one do with an Access project to migrate it to a
web application?
What is the approach if one does not have tests for the old system?
How could you assure not getting it wrong completly?
So is there any useful approach to a migration?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ed Prochak
software-solutions.de> wrote:
> Well I guess this question may be quite interesting. Now how should
> one approach migrations. Or should one avoid them like the plague.
>
> Here's one opinion about it:http://www.joelonsoftware.com/articles/fog0000000069.html
>
> So, this clearly meant don't do it.
He fails to mention lack of architecture/design/implementation
documentation. "Self documenting code isn't" - me
But there can be reasons for migration that override his arguments.
>
> Now what should one do if one has e.g an DBASE III or so project
> today? Or what should one do with an Access project to migrate it to a
> web application?
>
> What is the approach if one does not have tests for the old system?
> How could you assure not getting it wrong completly?
>
> So is there any useful approach to a migration?
>
> Regards
> Friedrich
You hit some of the key points:
Identify the functions and features of the current system.
Keep what features are still desired, discard other features (bugs)
from the old system in the functional documentation of the new system.
Develop test cases. Run them on the old system as the benchmark. Now
when the new system is ready for test, run the equivalent tests on the
new system.
Careful planning is how you avoid getting it wrong.
IME, it is easier to develop a new system based on a working old
system.
Two related real cases:
1.Worked for a company where I enhanced the proprietary OS for one
project. I didn't need to throw it out and rewrite because it was well
designed and documented.
2.Another project at the same company rewrote the OS completely. Why?
the original was in assembler (Intel 8086) and they wanted to move up
to newer processors.
I contend both decisions were right.
Sometimes throwing out the old code is the right choice.
ed
H. S. Lahman
> Well I guess this question may be quite interesting. Now how should
> one approach migrations. Or should one avoid them like the plague.
>
> Here's one opinion about it:
> http://www.joelonsoftware.com/articles/fog0000000069.html
I can't buy the author's view. The fact is that many legacy systems are
unmaintainable simply because they were built by people who had no clue
about writing for maintainability. Depending on whose number you look at
modifying an existing program requires integer factors more effort that
writing it the first place. IMO much of that inefficiency is because
most legacy code was written in an ad hoc manner. And modifying such
systems just tends to make them worse. (As the author points outs, a lot
of the problems are rooted in bug fixes.) At some point it is simply not
possible to continue maintaining the code because of the cost in resources.
In addition, legacy systems can be using outdated technologies.
Typically the problem here is that the technology was not isolated so it
appears ubiquitously in the code and to replace it one effectively needs
a complete rewrite. [Since I've been in the business there has been five
major changes in both UI and persistence paradigms, yet applications are
still written without isolating the UI or persistence paradigm de jour.]
However, as the author mentions, complete rewrites are notorious
opportunities for failure. There are three reasons. One is that
developers are usually lousy at estimating large projects and they
always estimate low, especially when they feel, "We already know how to
do this!". Is it reasonable that an application that took a shop with 10
developers ten years to develop can be rewritten in a year by those same
developers? Not bloody likely.
Another reason is that nobody bothered to write down the requirements.
IME shops with code maintainability problems have a very high
correlation with shops that don't have detailed requirements for their
systems written down someplace. So the existing code has to be reverse
engineered. The problem with reverse engineering is that it just repeats
the mistakes of the past because it is difficult to tell design
decisions from requirements. So the shop just rebuilds the same problems
and as the development proceeds it becomes harder and harder to
incrementally add to it. And, if they do finish it, it will probably be
nearly as unmaintainable as the old one.
The third reason is that the key designers are usually the same people
that were involved in the original construction because they know more
about the problem space. If the original code was not built for
maintainability, why would one expect that the new system would be
maintainable? Unless they have had a major epiphany they are just going
to repeat the same mistakes.
[Note that maintainability is critical even in original development when
the application is large and complex. That's because once a skeleton of
core features is implemented, everything else is effectively an
incremental addition (i.e., maintenance).]
So you need to replace the legacy code but you can't do it all at once.
What to do? The first thing to do is to make sure everyone is properly
trained in how to design and implement large systems properly. The
traditional ad hoc development from the Hacker Era simply doesn't cut it
and the developers must put aside the techniques that got the
application into trouble in the first place. For example, if nobody
knows how to properly partition a large application, the result is going
to be a disaster no matter how well code level dependency management
refactoring is done.
The second thing is to do piecemeal replacement where only individual
subsystems are replaced, one at a time. There is a systematic approach
to this that avoids a lot of the problems with full replacement. That
approach yields useful results at relatively short intervals and it is a
*much* more manageable process. [See the "Piecemeal Replacement"
category of my blog.]
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Marco
software-solutions.de> wrote:
> Well I guess this question may be quite interesting. Now how should
> one approach migrations. Or should one avoid them like the plague.
>
> Here's one opinion about it:http://www.joelonsoftware.com/articles/fog0000000069.html
>
> So, this clearly meant don't do it.
I'm not sure where you get "don't do it" from the article. Assuming
you have a paying customer ( internal or external) that wants this
migration then by all means do it. The article says don't throw all
the code away and start from scratch. BUT if the whole thing
(database, development language, etc) is obsolete then one just might
have to anyways.
>
> So is there any useful approach to a migration?
Read Michael Feathers "Working with Legacy Code" book.