Not long ago I discussed why most code is crud. But today I saw a thought-provoking post by Chad Fowler that got me thinking … what is existing code actually good for?
Chad opines that using an existing implementation as the specification for a new one is begging for trouble, even if the existing implementation is “successful”. He says:
… almost all production software is in such bad shape that it would be nearly useless as a guide to re-implementing itself. Now take this already bad picture, and extract only those products that are big, complex, and fragile enough to need a major rewrite, and the odds of success with this approach are significantly worse.
Existing code is good for discovering algorithms—not complex, multi-step processes.
Well said. I had the misfortune of working on a huge “existing software as spec” project that ultimately failed for reasons of the client’s overall business health, but it may well have failed for the reasons Chad mentions above if given half a chance.
I used to think such a project was “hog heaven” for a software developer but now I tend to agree with Chad. If it’s such a great spec, why is it being replaced? And the code itself is almost guaranteed to make you go blind if you look at it for long — simply because most code is crud.
To drive the point home even further, the project I’m talking about was extensively documented. I’m talking technical documentation, in two huge three-ring binders. But a combination of platform limitations and the practices of the original casual programmers simply meant that the technical documentation would cause you to go blind as well — and it’d put you into a coma and cause your cerebral cortex to explode.
So, as Chad says, existing code is good for discovering algorithms and implementation details. The application itself is often sometimes useful as a text fixture — if you can drive the UI or write unit tests against pieces of it to discover how it responds to particular stimuli, that can be enlightening. If you can use something like Camtasia or a code coverage tool against a workload driven by actual end users, you may discover some of the hidden byways of the application.
But, you will not find it a comprehensive and accessible specification or requirements document. Although, I’m still thinking it’s better than what passes for specs or requirements that you beat out of the client with a crowbar coax out of the client.
But then there’s the whole issue that if you’re not doing Big Design Up Front (BDUF), or if there are things that are broken in the use cases or UI metaphors of the existing app, such a comprehensive spec is rather useless to you anyway.
Sure, the client tells you the existing app is fine except it won’t scale, and they want everything exactly the same to avoid training issues.
That doesn’t last long in the real world though, as actual users come to you when they hear about the rewrite, falling at your feet and thanking you for saving them from this hideous software monster that has been eating them alive for years. Thank God someone is finally going to speed up the loading of that critical form, remove that stupid limitation on how many line items you can have in an invoice, and implement all the new use cases that have cropped up in the past five years. Before you know it, you have a stack of change requests a foot high.
Which reminds me: how about writing new software from scratch that talks to a legacy database? You know, the kind where each invoice lives in a record with field names like ItemCode14 and Description12, where every field is a varchar to avoid “premature optimization”, and no one ever bothered to index anything? All of which is jealously guarded by a DBA who won’t let you change any of it?
No, existing applications are not a slam-dunk, and quite possibly, in any given case may be less than no help at all.
