war of the bugs

There is a lot that has been said and written about why re-writing a legacy application from scratch is a bad idea. The introduction to Clean Code by Robert C. Martin covers it in some detail. My favorite recent tweet from @ziobrando was:

“Legacy is whatever you’re afraid to change.”

And yet we can’t deny the urge all developers have to start afresh. Sometimes it’s just so much easier to write new clean code than it is to get down and dirty with someone else’s bad code. The difference is that the legacy application who’s code you so abhor, well, it’s in production. Your new application, which is going to be like, amazing; it’s just a twinkle in your eye. How then does one reach the Minimum Viable Product from the perspective of your users? They quite like the current one, nothing wrong with it really, it works. Requirements might form along the lines of: just make the new one do everything the old does for starters.

That legacy application, as full of bugs as it may be, has hidden depths which may obscure many implicit requirements and conceal important edge cases. It’s earned its right to be there, over countless iterations and releases.

In the most recent dramatization of H.G. Well’s War of the Worlds, starring Tom Cruise, the super advanced aliens rise from their hibernation below the Earth’s crust, and steadily begin to exterminate humanity on their path to global domination. But just when it seems all hope is lost, our best weapons of no avail… the aliens are undone… and we hear Morgan Freeman’s voice:

“…from the moment the invaders arrived, breathed our air, ate and drank, they were doomed. They were undone, destroyed, after all of man’s weapons and devices had failed, by the tiniest creatures that God in his wisdom put upon this earth. By the toll of a billion deaths, man had earned his immunity, his right to survive among this planet’s infinite organisms. And that right is ours against all challenges. For neither do men live nor die in vain.”

War of the Worlds water drop

 

 

2 thoughts on “war of the bugs”

  1. Couldn’t agree more with the “it’s in production” argument. As a systems integrator, even the well specified software I use, like routing daemons which have a public protocol and ‘best common practices’ document, couldn’t be re-engineered in a reasonable time because of all the edge cases and behaviours which are only ‘specified’ and handled in the code. Another case in point is a filesystem. A common rule of thumb is that a FS has to ‘bake in’ over 5-10 years, after which you sure as fsck (Unix pun) can’t rewrite it without resetting that clock.

    1. Yeah, great examples, especially something as fundamental as the file system. I was thinking of own experiences with in-house desktop applications, with relatively small captive user bases. Once it gets into the public domain, a large user base with many varied requirements, gradually satisfied over the years, many versions, the problem must compound even further.

Leave a Reply