One day, you are sitting at your desk, minding your own business. A developer walks up looking flustered, and tells you that there is a query running 5 hours every day, and that the stored procedure code is simply awful. With just a few hours of refactoring and tuning, you know that you could make it go blazingly fast. What do you do? What…do you do?

The decision sounds easy, and if you have any passion for technology, your immediate impulse is almost certainly going to be, "Fix it, and immediately!" Is this the right answer? Perhaps so, but you're thinking like a technologist rather than a (good) manager. A manager will first have to consider other questions such as:

1. Are any other processes being affected?
2. Are users waiting on this query to finish, or is this an automated process that delivers results asynchronously?
3. How long will it take to test?
4. How many of the manager's pointy haired colleagues are likely to get involved?

If a developer discovered the horrible code, it is likely that the answers to this question will be:

1. No
2. Automated
3. Far longer than to code
4. Nearly all of them, plus a few of their friends and relations

In addition to these obvious questions, a manager will also wonder why the pre-deployment code review didn't pick up this problem at the right time, when any necessary changes were practically free, and why the testers didn't notice that the process was running for a long time, investigate, and wave a black flag at the appropriate time.

If you trust your team not to willfully cut corners, and deploy malodorous code, then it's likely to be technical debt, a known and documented weakness in the code that the team had to live with due to the restricted time allotted to development.

Technical debt is a constant source of frustration. From the second they deploy a new feature or product, most good developers will be aware that they could have done almost every task better, from requirements gathering to design to code. As a data architect, I agonize over new structures, naming, how best to apply constraints, and so on, striving for the best possible solution in the time I have. Often, as soon as I've released my design to the developers and they start accessing the table structures, I realize a much better way to solve the problem. I know the fix might only take a few hours, and my impatient self really wants to halt the project while I do it. Of course, unless I can prove that it will save everyone appreciable time, in the long run, or know that it will manifest itself as a major road blocking issue that will affect the end user, it is usually not worth the cost to the project.

In order not to disrupt the development process, technical debt can only be repaid when the time is right. You just have to grit your teeth whenever you notice that long-running query and be patient. A time will come to reward your patience because you'll be able to sequence the required work in the most efficient way. Chances are, why you wait for your chance to tune that 5-hour procedure, the development team will also realize that they need to add a new column to its output. Now, you can fix, tune and test it in one go instead of two, saving many hours of testing and planning time, and then many hours of processing and deployment time. Everyone wins from the accounting team to the end user to the programmer in between.

Louis Davidson (Guest Editor).