SQL: Lack of consistency in development says so much about your team

I wrote last week about how I don't like unnecessary abbreviations. It's all part of a desire to see higher quality code, because that costs less to maintain and support.

Another key issue that troubles me in development is when I see inconsistency.

Single Brain

When you have a team of people doing work, you need to endlessly try to make the outcome look like it's come from a single brain. And equally importantly, make it look like it's come from a single brain that cares about quality and attention to detail.

I might be a bit anal on these things, but let me give you a few simple examples of where I've seen this in SQL Server, one from ASP.NET, and one from Azure DevOps. I can give you many customer site examples, but these might be better as you might recognize them.

SQL Server Examples

When I saw the graph functionality added to SQL Server 2017, I noticed the new functions had names like NODE_ID_FROM_PARTS and EDGE_ID_FROM_PARTS. Now that's all well and good, but this is in the same product with functions like DATEFROMPARTS, DATETIMEFROMPARTS, etc. Now I prefer the underscores in the graph functions, but how does a single product end up with this sort of difference all over the place?

We're used to seeing Intellisense in SSMS for functions like this:

All good. But note how the Intellisense shows for this function that was added almost a decade ago:

Is Param1, Param2, etc. really the best the developer could do? But even that's better than the graph functions that I mentioned:

All the other functions have their own T-SQL documentation page. Not these ones. And an SSMS F1 search for help on them takes you to a generic page for help on the SSMS editor.

Another lesson is that even if you don't like a current scheme within a product, you don't just randomly change it to something you prefer. You continue with the scheme for the sake of the overall application.

In SQL Server, we already had tinyint, smallint, int, and bigint. We also already had smalldatetime, and datetime. So if you were going to introduce a new data type that had a bigger range of values, and higher precision than datetime, what would you call it? I'm hoping you would have said bigdatetime, and not datetime2 like we ended up with in the product.

ASP.NET Example

One of the biggest contributions of the .NET Framework was that it cleaned up most of the mess that had evolved in the underlying Windows 32/64 APIs. It didn't matter what the collection of things I was working on was (e.g. IPAddresses, SqlParameters, etc. ), I knew that I could call the Add() method to add a new one, and the AddRange() method to add several.

I remember sitting in a room when we were first shown the new ASP.NET membership system. While everyone else in the room seemed impressed about how easy it was to implement, I think I was the only one in the room looking at new methods like AddUserToRole() and AddRoleToUser() and wondering why on earth they weren't User.Roles.Add() and Role.Users.Add().

Azure DevOps Example

It even happens in UI. I was working in Azure DevOps the other day, and many of the buttons said OK but other buttons said Ok. How does this happen? Am I the only one that jars on when I see it?

I suspect these teams are lacking a group of cranky old guys who look at these things and say "no, have another go".

Attention to Detail

I spent time working as a customer engineer for Hewlett Packard in the early 1980's. They really did make amazing minicomputers that were a cut above anything else on the market, particularly in the commercial space. When we were doing work on those machines, we prided ourselves on the quality of the maintenance work as well.

When I was helping out in other offices though, every now and then, I'd start to work on a machine and find things like a few screws missing. The minute I saw that, I knew that the person who'd worked on it last, didn't share that same attention to detail. I then had an uneasy feeling about working on that machine, as I knew I could be working on something with unexpected issues.

What else wasn't put back together properly?

And it's the same with applications. If the UI or the APIs are inconsistent, what does that portray about the quality of what's under the surface?

2 thoughts on “SQL: Lack of consistency in development says so much about your team”

  1. I worked with a system that had three spellings of Workorder on the same page…

    Workorder,WorkOrder and Work Order….

    Plus another system that had the term "Weekending" for the end of the week…

    Consistency needs to be defined at designed time, especially if dev teams might be coming from countries other than where the systems are used

    1. Agreed Rob. Developing (particularly UI) in a language that's not your native language is an additional challenge though. I could now create something like a simple Chinese UI but I'm sure it'd end up laughable to a local.

Leave a Reply

Your email address will not be published.