Opinion: Sticking with a plan even if you don't like it

Something I really struggle with in this industry is when newcomers to a system want to change standards within existing systems because they think something else is better. It’s a sign of immaturity yet it often applies to people who should be senior. Many system architects fall into this category.

For example, a vendor system that I’ve been working with has single column primary keys in all tables, and all the primary key columns are named PKey_ID (I’ve changed it a bit to protect the guilty). Now I can’t say I like that naming at all, but that’s not the point. There are a large number of tables that already have that naming scheme.

Enter the new architect who has a purist view where he wants to name the columns ID instead. Again, I really dislike this naming but I don’t care what the vendor does, apart from being consistent.

Yet what the architect does is change so that a handful of tables now have ID. That is a really poor outcome. If he really wants to change them, then come up with a plan to change all of them.

I see the same thing in SQL Server.

We already had:

• tinyint
• smallint
• int
• bigint

And we already had:

• smalldatetime
• datetime

So when a larger precision version needed to be added, it wouldn’t have taken Einstein to come up with bigdatetime.

The answer certainly wouldn’t have been datetime2 which is what we got.

Oh, you say, but datetime2 is really a combination of the new date and time data types, and we already had a datetime data type, so it couldn’t be that.

Yes, but what then happened with datetimeoffset? It’s a datetime2 with an offset, so why isn’t it datetime2offset?

What’s the answer? I’m not 100% sure but I wish these teams had more cranky old dudes who look at proposed designs and say “nah, have another go at it”.

2017-11-14