More Technical Debt Tips

So you followed all my tips in the first installment, but you’re still worried that your code might be maintainable? Here are some more:

11. Forced to fix a bug? Don’t worry, you can reintroduce it a couple of releases later, as long as you remembered not to add a regression test for it.
12. If you must document code, don’t take the opportunity to explain WHY it’s doing what it’s doing. Just describe the obvious. Learn from the masters at Microsoft:

    // Initialize the column to '0'
    ColumnToSort = 0;
    // Initialize the sort order to 'none'
    OrderOfSort = SortOrder.None;

    No, really, that’s not made up – see for yourself.

13. If you have to generate a lengthy SQL statement, avoid any kind of formatting of the code that might make it readable. Instead, cram it all on one line such that you can only see a small part of it at once.
14. Avoid unnecessary timezone calculations by living on the Greenwich Meridian and only testing your code when DST is not in effect. Or preferably not at all.
15. Threading is your friend. Find obscure ways to make sure your functions are not re-entrant. When reports of random failures come in from production environments, simply say you can’t reproduce them.
16. Carefully read any coding standards that apply to your project and commit them to memory – otherwise there is a risk you might comply with part of them by mistake.
17. A multidimensional array is a fine construct for storing your tabular data, but only if you refer to all your columns by numbers and don’t document them. Better still though, is a comma-separated list of pipe-delimited strings. For bonus points, use a delimiter that only rarely occurs in the actual data.
18. Use floating point numbers for your currency calculations.
19. Although cluttering up the code is normally a worthy cause, don’t waste your time validating user input. Rely on bug reports to find out the interesting effects of the ‘unexpected’ things they entered.
20. Refactor. Because you feel like it.