Do you rebuild or enhance enterprise applications ?

Question

When I walk to work (in London) I see loads of redevelopment on commercial buildings. One of the first this I notice is they knock down the old building and build from scratch. They end up building some of the most advanced and stunning to look at buildings.

Bearing this in mind, when I look at old legacy code, in existing applications, I think shouldn't we build from scratch?

I have seen and worked on applications that have been around for, and all you end up doing is propping them up.

I have never been involved in a project where the old application has been scrapped and we start from the ground up. Maybe the business are worried about the impact, wonder why people in the building and construction world don't have the same sentiment.

So do you rebuild or enhance enterprise applications ?

Cheeky favour - can someone reopen this as I think there is more on the subject.

Answer 1

See Joels article (which I agree with) on why you shouldn't rewrite an application from scratch.

Refactor it yes, but re-write, No.

Things You Should Never Do

Answer 2

Legacy code is code that works. Rebuild only when you have to.

One thing I have learnt in the last 10 years, 'old horrible horrible code' is what makes the world go round. Shiny pretty code only exists in textbooks or toys, and just being someone's else code is enough to take the shine off the greatest code.

It sucks being a pure maintenance programmer instead of one of these fly-by-night cowboy consultants who always work on new stuff, but realistically, 98% of programming is maintenance, and new stuff becomes old stuff faster than you might think!

But then I walk past the Tower as well as the Shard on my way to work :)

Answer 3

The classic consultant's answer: it depends. (I've been on both kinds of projects.)

If the cost to add an needed enhancement or fix an existing defect is modest and predictable, then in-place repair makes sense.

If it is at least as economical to slice of the new (or updated) functionality into a cleanly decoupled service, maybe it's time to start deconstruction. Unlike the building trades, it's possible to migrate functionality without tearing down the old system all at once.

Part of the reluctance to "big bang" projects comes from factors such as these:

• IT folks don't have a strong deliver-per-the-oringinal-estimate reputation. (And, yes, there are plenty of reasons and plenty of "blame" to spread around.) Business folk often prize predictability over blinding brilliance.

• Technical elegance without accompanying bottom-line benefit is hard to justify.

• Buildings are tangible. You can impress your prospective customers with how fancy your building looks, but not with the beauty of your Service-Oriented Architecture (unless you're in the software business).

• Buildings are tangible. You can see the progress as one is being built. That's where the agile folk have such a good selling point: deliver business value with every iteration, rather than promising utopia in a future release.

Point being that realistically, believably, and reliably addressing issues such as the above will help make the case for a replacement project.

Answer 4

There is always a tradeoff here to be made by the business. From a technical point of view, we see new tools, frameworks etc. and think to ourselves: "hey, if we use FrameBling 2.0, we would be much faster, so let's just rewrite this crap, and do it right this time". Over and over again, it has been proven that complete rewrites in most situations are just a techie dream come true. You're spending the first 60, 70 % of design and development rebuilding already existing features, in your new shiny OneTrueBusinessApp. Not generating a penny of business value during this time. It can only work if the current situation is generating no more revenues or other income streams whatsoever. Nothing wrong with starting from scratch there, since there is nothing to loose.

But this is not the common scenario: you bet that there is an enterprise app, developers are complaining all the time about the crap code that former devs left behind. But then? The best advice I can give is to head over to "Working effectively with legacy code" by Michael Feathers, and get yourselves out of this mess.

Prepare for a tough ride though, as refactoring existing apps can be a real tough ride. Good luck!

Answer 5

A few years back I worked on a system converting an old Foxpro system into Java. We got all the infrastructure, DB, GUI etc. up and running fairly quickly - then we spent months trying to sort out all the business rules that had been hardcoded into the system with no documentation and none of the original developers kicking around to tell us what was going on.

The thing about old code is that it's organic. It's a living, breathing thing and rewriting it means that you need to make sure you've caught all those bizarre edge cases that have already been ironed out in the original. Couple this with the time it will take to do where no new functionality is being added and the potential for introducing new bugs and I can see why management are loathe to let you rewrite from scratch.

Answer 6

Rewriting from scratch is costly, but it may be a decision to consider if even small changes threaten the application's stability. Typical examples are applications

• which have been around for a long time, and/or
• which were originally written using poor design standards, and/or
• which have grown exponentially since the first design, and/or
• which never had good documentation.

In a good modular design you might want to re-use certain modules, but in that case you may not have the above problems in the first place.

Answer 7

I would only consider a rewrite if it's to change the technology/platform of the product. If not refactoring is the way to go IMO, because you never end up with the clean code base you were dreaming off.

Answer 8

If it ain't broke, don't fix it. That's the best mantra to tell yourself in most of these situations. I both maintain and design new enterprise systems, have been for a few years. And unless you work for a glorious company where time and expense don't matter...again, if it ain't broke, don't fix it.

We usually rewrite things only if they are proving that leaving it as-is is more of an expense, personnel- or money-wise, than it is to rewrite it. Only then do we move on it. Interesting this came up now, as I'm in the process of moving our old source control system over to a new one. I'm trying to clean up as I go, so I'm investigating old one-off legacy systems to see if they're still in use. To my surprise, I've stumbled across quite a bit that's still in heavy use within certain pockets of the company, but nobody's complained about it or asked for enhancements for years. What benefit would we gain in rewriting something that's obviously working well enough for who needs it?

To be a devil's advocate against myself, there are also times where it might make sense to rewrite something, but not because it's being a drag. Maybe it encapsulates important data that can be re-used somewhere else in another system, or needs to plug into some other process. Some of our old ASP apps would have a hard time doing this well unless we rewrote them in .NET.

There are tons of things to think about with the business impact, as you pointed out. We once re-wrote an ancient ticketing system that was working just fine, only to give some new reporting capabilities and make it look slicker. It was a disaster because we didn't manage the change very well at all with the stakeholders and eventual users of the system...they weren't trained well, the system was overly complicated with too many bells and whistles, and we caught a lot of flak for it. Just an example. Other systems where we properly deal with that aspect of the change have gone much more successfully...but the point of that story is to not rewrite something just for yourself without involving everyone. Which can pump up the expense of the project dramatically if you don't watch it.

So, the ambiguous answer you probably weren't wanting was "it all depends." :) Though a lot of us don't like the fact (including myself a lot of the time), we're paid to provide business value, not necessarily to create picture-perfect code. Remember that when these decisions are being made and you'll prove valuable to those up the chain.

Answer 9

Netscape decided to re-build their Enterprise Application. The Result was Netscape 6 after years and years, and we know all the results.

As horrible as old Code may look like, most of it is usually for a reason. And by the way: Are you sure that the "horrible" Code does not contains some hidden gems, like that bugfix for a chinese customer using turkish keyboard layout that requires some special input verification? Those are the fun ones when you re-introduce a fixed bug and customers start calling you names!