It is inevitable that anyone who inherits responsibility for an application will experience that feeling of nagging apprehension. Some signs of doom are universal, the same whether it is a legacy code base, a bought-in system, or group of SQL Servers. It starts with the shiftiness of the manager breaking the news, telltale beads of sweat on his or her brow, the ingratiating smile. Any experienced IT worker, from project manager to DBA, from developer to sys admin, will then immediately, and nervously, starting looking for the indications that will soothe their fevered brow, or confirm their fears.

You might think that one would start with the overall design, get an overall impression of the application. However, it seems that many seasoned professionals go straight to the details, to the individual methods and procedures. They are looking for three things: whether the creators of the application cared, whether they became embroiled in a desperate struggle to make it work, and whether they had, at least, the necessary competence.

• Did they care enough about the code to:
• Avoid very basic mistakes such as senseless type conversions
• Avoid needless complexity (5 lines of code where a few characters would do)
• Make each method, procedure or function as clear and lean as possible
• Explain with comments why the code or data structures were written that way.

If there is insufficient care in the detail, then it is likely that big problems are afoot, problems such as duplicated code, God objects, contrived complexity or inappropriate intimacy. Worse than the problems that make refactoring difficult are the ones that kill scalability and performance. This in turn leads to desperate measures that leave their mark. In a database, this can mean NOLOCK hints, no indexing, improper function use, hints everywhere, and much more. Gail Shaw suggests that quick server audit can offer a useful forewarning of such problems. Look at the values for settings such as ‘boost priority‘ or ‘lightweight pooling‘. If they are different from the default settings, it is a sign of a frantic search for a “please go faster” switch, and an indication of serious code and other problems ahead.

I’d love to know what “early warning signs” you look for when exploring new code, or new servers, and how you find them. Do you look at specific details, or other, broader indicators?

Cheers,

Tony.