In my usual twitter doom scrolling, I came across this post the other day

Now it’s pretty obvious to me that this is one of the standard “engagement bait” posts that are commonplace nowadays. It’s designed to polarize opinions and thus the resultant “discussion” becomes a lot more inflammatory and thus succeeds the goal of engagement.

But putting aside the obvious intent, when I was scrolling through the replies, one thing stands out – man oh man are our tech egos out of control.

No-one replies with “Whatever I choose, it probably won’t really matter to me, because I’m like 99% of other IT professionals – I’m building moderate scale systems for my company“. Because that doesn’t sound impressive does it? Everyone has to chip in with replies that sound as if they are building a distributed microservice, event-driven, multi-region failover, horizontal scaling service mesh with five different caching layers. Nobody wants to say “Yeah, we’ve got 20 or so concurrent users“, they want to say “We’re ready to support 400million customers

Now I’ve got no problem with a little face-saving and truth-inflating when it comes to posting on social media 🙂 But the problem comes when our obsession with internals takes our focus away from things that ultimately will be of more values to our users:

  • Does it crash when someone puts in an invalid date?
  • Does it handle the situation when Karen in Sales clicks the “Process” button twice?
  • Can it be viewed by people with accessibility challenges?
  • Does it do the function that is actually requested by the customer?

Not every software project is one funding round away from becoming the next Netflix, Amazon or Uber. Most software projects have a much more mundane reality. They’re built for a few dozen employees, or a few hundred customers, and are not intended to appear in next months “What’s hot in tech” article in Time magazine.

Given that a modern budget laptop can do 1000s of database transactions per second, you obsessing about power of UUIDv7 over other alternatives is perhaps not the best use of your time. For many workloads, a couple of CPUs (either your own or on a cloud service) with a functional data-centric front end (eg Oracle APEX) is going to comfortably handle traffic levels that would have seemed impossible a decade ago, and hence let you focus on the stuff that really matters – the customer functionality and the customer experience..

Yes, there are applications that genuinely require massive scale, will need sophisticated architectures, and hence a robust discussion on the database design implementation specifics. But perhaps don’t start with that assumption – you probably are not building the next global platform.

(Puts marketing hat on briefly…) Don’t take my word for it. Give Oracle APEX a go for free and you’ll probably find that’s all you need to get great applications and happy customers.

Having an ever growing amount of tech knowledge is a great thing to aspire, just make sure you’re not really focusing on an ever growing amount of tech ego.

One response to “Keeping your tech ego in check”

  1. I absolutely agree.

    I look at a lot of systems and see crazy things. Recently I looked at a system with 500 tables and only a single one had a primary key. There were NO foreign key constraints in the database at all.

    I had to remind the consultants working on this project: Their business is running. They are successful enough that they have the money to hire us to help them. Let’s help them. It is as good as it could/should be? Nope. But, it does work because their business is running.

    That said, I do encourage folks to log technical debt in these situations. Just put it into the backlog into a technical debt category. It could lead to the next project to ‘eliminate the years of technical debt’.

    I recently helped a DBA who took over from the ‘very long time DBA’ who ran everything for decades before the new DBA took over. Last week we eliminated 25+ years of technical debt from the Oracle Networking files on a production database server (sqlnet.ora, tnsnames.ora, and listener.ora). Together we did a lot of discovery (How many of these TNS aliases are actually in use?, How many of these heterogenous services are actually in use?, Why are there two listeners listening on different ports?, etc.) Once finished we eliminated 100s of lines from the files and organized everything so that it was trivial to understand (AI: Take this tnsnames.ora file and sort it into two groups alphabetically aligned within each group. Put Oracle Database aliases at the start and Heterogenous Services alias at the end.) and to support going forward, AND, (by far the most important thing) we also documented every change that we made. 🙂

    Even though we did all that work, was the production database working just fine before hand? Yep, it was.

    My first response to the “UUIDs have no place as primary keys”: Sure. For any new system, we should probably not use UUIDs as surrogate primary keys. If we have them already in places, let’s put a ticket into the backlog and check in with the business on the important of addressing this technical debt. But, remember the business is already running and there are probably things that will have a direct business impact that will be more pressing for us to address first.

Leave a Reply

Trending

Discover more from Learning is not a spectator sport

Subscribe now to keep reading and get access to the full archive.

Continue reading