A common saying from parents, teachers, and many managers, is that you should follow their instructions and not necessarily their behavior. This is a very human thing to do, with many of us struggling to follow the behavior that we ourselves want. Instead, we follow the vagaries of our moods and desires. We do this even as we tell others to do things that we don’t bother to do.
It’s not just human behavior, but it applies to how many companies deal with their customers. Microsoft talks often about taking advantage of new features in code and using the platform to solve problems. They dislike adding simple “syntactic sugar” (like a numbers table), and instead prefer you build the code to handle some of these simple tasks.
However, they don’t really follow this advice, as Andy Mallon showed with a recent post on why not to use a couple of their “recommended” stored procedures. They’re not well written for modern code, they have limitations (or bugs), and could be considered a security risk.
To be fair, I know that changing code in something that works is always dicey, but at the very least, moving from varchar() to nvarchar() shouldn’t break anything. If there are edge cases, then write some tests and rebuild the code to work better. Maybe, more importantly, these procedures ought to model good code, as Microsoft would recommend to their customers.
There are a lot of places where different products at Microsoft might not use SQL Server well, and I understand. These might be software developers that don’t know a lot about how to perform good data modeling or even how to take advantage of SQL Server code. However, at a company with the resources Microsoft has, I’d expect them to form teams to handle these tasks and then review and suggest changes to software like Dynamics, Sharepoint, etc. Even if they can’t use the latest features in the SQL Server codebase, they ought to model good practices for all versions.
For many of us, we might act similarly inside a company. Often we write code out of habit, and perhaps, to expeditiously get work completed, even when we know better. Using SELECT *, leaving out error handling, and more are habits that far too many of us embrace, far too often.
Start making some changes today. If you know there are better practices you should follow, then take the few extra moments to implement them. If you don’t know of good practices, start compiling a list, asking questions, even post an idea or question in the discussion for this editorial. We all could write better code, and that starts with us actually making an effort to model the behavior we might preach to others.
Steve Jones
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
