This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Retreaded: StranglerApplication
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
When Cindy and I went to Australia, we spent some time in the
rain forests on the Queensland coast. One of the natural wonders of
this area are the huge strangler vines. They seed in the upper
branches of a fig tree and gradually work their way down the tree
until they root in the soil. Over many years they grow into fantastic
and beautiful shapes, meanwhile strangling and killing the tree that
was their host.
This metaphor struck me as a way of describing a way of doing a
rewrite of an important system. Much of my career has involved
rewrites of critical systems. You would think such a thing as easy -
just make the new one do what the old one did. Yet they are always
much more complex than they seem, and overflowing with risk. The big
cut-over date looms, the pressure is on. While new features (there are
always new features) are liked, old stuff has to remain. Even old bugs
often need to be added to the rewritten system.
An alternative route is to gradually create a new system around
the edges of the old, letting it grow slowly over several years until
the old system is strangled. Doing this sounds hard, but increasingly
I think it's one of those things that isn't tried enough. In
particular I've noticed a couple of basic strategies that work well.
The fundamental strategy is EventInterception, which
can be used to gradually move functionality to the strangler and to
enable AssetCapture.
My colleague Chris Stevenson
was involved in a project that did this recently with a great deal of
success. They published a first
paper on this at XP 2004, and
I'm hoping for more that describe more aspects of this project. They
aren't yet at the point where the old application is strangled - but
they've delivered valuable functionality to the business that gives
the team the credibility to go further. And even if they stop now,
they have a huge return on investment - which is more than many
cut-over rewrites achieve.
The most important reason to consider a strangler application
over a cut-over rewrite is reduced risk. A strangler can give value
steadily and the frequent releases allow you to monitor its progress more carefully. Many people still
don't consider a strangler since they think it will cost more - I'm
not convinced about that. Since you can use shorter release cycles
with a strangler you can avoid a lot of the unnecessary features that
cut over rewrites often generate.
There's another important idea here - when designing a new
application you should design it in such a way as to make it easier
for it to be strangled in the future. Let's face it, all we are doing
is writing tomorrow's legacy software today. By making it easy to be
strangled in the future, you are enabling the graceful fading away of
today's work.
Previous Topic
