It’s kind of old, but somewhere I stumbled on Ned Batchelder’s article on deleting code. At first glance it looked to be a trivial subject, but it actually turned out to be an interesting read. I have been guilty of leaving dead code lying around, but on the other hand I have clipped stuff that I later wish I had back. Source code control helps, but then it depends on how often you check in your code.

A Retooling Project
Nevertheless, it is an interesting article and got me thinking about a side project that has me rewriting and updating (in C# and some SQL) much of an old system, a mix of ASP, VB DLLs, C++ DLLs, and SQL. (The VB and SQL are getting the overhaul.) I am finding maybe 35% of members, columns, functions, methods, and stored procedures are not used. At all. Some have me scratching my head, wondering how a GetRequest differs from a RetrieveRequest — turns out they differ only in the spelling of the function and in who calls them, but otherwise they’re twins, as are their corresponding stored procs. Neither is strictly dead code, but we certainly don’t need two of them.

The rub is that it is primarly my code. It was a project that was driven to market too fast by the sales force. They held development hostage, claiming they could not sell other products unless they could offer this “bonus” product as well. Well, the product made it to market on-time and fully-functional — or, it appears, extra-functional. But it is awfully complex and I was much greener in this environment at the time, leading to some unforseen issues. Since its introduction the product has worked well except for some ill-handled conditions that I patched over manually, behind-the-sceens.

This behind-the-sceens patching occurred whenever a certain error condition was met — an error condition that has been more prevalent lately, leading to a lot of behind-the-sceens scrambling. In the past, management would not commit any resources to fix the problems since customers were not complaining, but we’re now in a position to allocate time to clean things up. Plus, a retooling allows us to leverage some new technology and some old lessons.

Lessons Learned
It has me thinking about lessons learned in the life cycle (so far) of this product.

1. As always, don’t let sales drive development schedules too hard — everyone knows this rule but it still happens. Continue to educate them on the downsides to driving things too fast. Tip: Sales people have very short attention spans and want a few quick, punchy points to take away. Another tip: if developers are driven too hard up front, they often are too burnt out to go back and “make it right” after the fact, not to mention convincing management that it will be worth the time when other things are waiting for attention.
2. Wherever possible, lean towards simple designs; complexity can get to a point where it starts to breed.
3. Without getting at-odds with simplicity, anticipate future requirements and create flexible systems to handle them.
4. Triple-check your work to eliminate duplicate or unused code. The point above about anticipating the future does not mean write code that sits dormant. Code for today’s possibilities.
5. Try to allow time to re-organize and re-factor throughout the project; you are bound to learn something once you get started.
6. Take care to handle unanticipated error conditions along with the obvious ones. Carefully think through the side-effects of failures. For example, would the system be left in an indeterminate state? This sounds obvious, but it does not go without saying.
7. Include monitoring and administration in your design. It is sickening to find out that a previously-reliable system hasn’t been working for a week and you have to go back and reconstruct data out of log files.
8. Document lightly as you code, then heavily when done. The heavy documentation stage will sometimes catch bugs before customers do.

Most of the above points I have read before, but for some reason they often get brushed to the curb in the rush to market. They really all boil down to one rule: slow down, look around, and walk with care.