First, a bit of backstory: I had to add a bit of functionality to a web page written by someone else (and possibly modified by even more people). If you're not a web programmer, you might only care to know that there are two instances when a programmer should check the input that a user fills into any form:
- After the user submits the form, but before it's actually sent to the server.
- After the form is received by the server, but before it's allowed to affect the database or user's session.
This might seem redundant, but if you want to keep your data clean and your downstream code reasonably safe from careless data entry (if not out-and-out maliciousness), it's the only way to roll.
Thus, I had put code in both places. For the pre-form-submittal code (#1 above), I merely added it to an existing function appropriately named "Verify()." So there was a bit of head-scratching involved when it was discovered that the web page had actually been submitted to the server before the error-messages popped up to complain about bogus input. As it turns out, someone had re-written the form to entirely bypass Verify(), but hadn't bothered to remove the function.
Which is when the analogy of obsolete code as driftnets jumped out and bit me on the nose. I won't re-hash earlier rants about code "housekeeping" paying for itself in the long run, simply because this makes a fair illustration. Particularly when you consider that the code in question wasn't all that complex--i.e. it could have been much worse. Even in that case, it would have taken my predecessor mere seconds to search for any other references to the function in the page and, finding none, highlight that function and hit the "Delete" key. In contrast, QA and I wasted at least an hour by the time the issue was filed, I'd located the code, debugged the problem, fixed it, unit-tested, merged, committed, promoted and swatted the issue back into testing. That obsolete code (i.e. the driftnet cut loose in a moment of distraction--or, for all I know, apathy) added the completely gratuitous cost of an hour's billable time to the project.
Even at offshore billing rates, the difference between seconds and an hour isn't negligible. Particularly when you multiply it by the number of times it could happen if you keep even one slob on a team--or skew the incentives toward raw code/features produced. Now, I've worked in this code-base enough to know that this kind of thing is a statistical outlier, which is probably why it still chaps my hide, even hours later. Even so, I hope that the real-world illustration of the difference between seconds and an hour makes the case in a way that no amount of ranting about code hygiene will do.
