Random thoughts. Not fit for general consumption. Parental advisory. Occasional sarcasm and irony ahead. No warranties, explicit or implied. No money-back-guarantee. Does not prevent hairloss, bad foot hygiene or acid reflux.

2007-12-03

When in doubt: chuck it out (and rewrite).

An interesting article about the BBC and Perl on rails appeared on one of the news-tracking sites I follow. This reminded me of some points I've made in the past.

Whenever I have to deal with legacy code operating way past its sell-by date I get this strong urge to just throw it out and start over. Now this never gives any sort of higher-ups warm and fuzzy feelings. This is not what managers want to hear. More often than not, they'll feel like chucking you out and finding someone more obedient and enthusiastic about tar pit-diving.

Managers never like to be told that a system they've poured money into should be scrapped and redone. I guess this is a legacy of defining "software engineering" as "engineering" when clearly it isn't.

Here's why: software in itself has no value - the knowledge it represents has value. The problem lies in the unrealistic expectation that a complex software system can be planned, designed, implemented and deployed -- like a bridge or a piece of road. But bridges and roads seldom have to accommodate dramatic new uses. Nobody expects you to build a road that 18 months from now needs to sprout new features for which there wasn't even a name when it was first built. Nobody builds a bridge and then says "well it needs to accommodate six more lanes and you should be able to land a plane on it".

It doesn't matter how much a complex system cost to put together. If extending it and adapting it takes more time and work than is reasonable, it should be fairly easy to calculate when you have recovered the cost of doing over again. (Provided that you know what you are doing and that you won't fall prey to the "if you are doing a new version we want these extra features too"-trap And even if you throw away every single line of code, you still have the knowledge -- you still know a lot more about what you need than you did at the outset.

Another interesting thing mentioned in the article is how the BBC outsourced a key part of their operation to another company, rather than building in-house expertise. It always puzzles me when organizations of considerable means do this. To me, if your success to a significant degree depends on your technological infrastructure, it is foolish, if not irresponsible, not to have expertise on those systems internally.For those who read various trade rags, BBC used to be an organization that took the technology they depended on seriously. Then at some point, the bean-counters figured that it would be okay to just outsource everything they could, making the books prettier, and thus bringing an end to the era when the BBC was a place where people would turn to learn. Where technical expertise was cultivated and grown.