Nuance, and The Necessity For Trust

“When you live on the shoreline, you can forget that there are people out there who don’t even know the ocean exists”
 — Me

Remember when you started in the world of Software Development (or, frankly, any field whatsoever)?
How wide open the vistas were, how challenging the problems were, and how much you didn’t know?
And how, years later, the vistas are still just as wide open, the problems are just as challenging as they used to be, and you’ve realized that, if anything, there is even more that you don’t know? (•)

The thing is, it’s not that you haven’t learned anything. The more in depth you get into a field, the more nuance you discover, the more weird/fascinating edge cases you find, and the more complexity you discover when you pull back the curtains. Edge Cases and Nuance essentially become the cornerstone of your existence, to the point where most of your discussion with your peers revolve around them.

And therein lies the rub. You can get so used to dealing with esoteric issues, you can easily forget that most of the other folks in your organization barely understand that there is anything even remotely complicated to what you’re doing. They, literally, don’t see the ridiculous amount of stuff that is going on behind the scenes, because, as far as they’re concerned, Everything Just Works! (no thanks to you of course…)

AN EXAMPLE
In a past life, my company (at the time) had an app, that, well, did stuff. It was a fairly simple thing, the user scanned some information, the app configured itself based on that, the user entered more data, blah, blah, blah. We built the first pass of this with Postgres as the back-end database, and It Was Good.

Well, time passed, and the requirements got a wee bit more complex. The app was now collecting a bunch of real-time data and streaming it to the database, data that we needed to process and act on pretty rapidly. We ended up using Cassandra to store/process this data, which brought with it it’s own set of headaches around consistency, availability, access mechanisms, and whatnot.
(For the non computer-types amongst you, think of this as swapping out a single delivery truck with a fleet of motorcycle-carriers. You can get a tremendous speedup, at the cost of way more overhead than you used to have)
(And for you computer-types, yes, that’s a terrible analogy. Whatever)

The problem here was that the Business folks didn’t see any issues. As far as they were concerned,
• “You’re just swapping out one database for another, whats the big deal? Databases are all the same, right?”
• “Why do you even need to swap it out? Can’t you just run it on a bigger server?”
• “Why don’t we put in Oracle?”

I trust you get the point. Here we were, freaking out over the optimal way to store and process time-series data, at scale, across distances where latencies actually mattered, and how to migrate from one storage paradigm to another. Meanwhile, as far as the business folks were concerned, not only was it not a problem, our stress levels around this indicated that we had no idea what we were doing

TRUST
There really is no easy answer around this. If you’re lucky enough to have Trust across the organization, then you should take the time to explain the situation to the others. Oh, you don’t need to get into the nuance, but you should be able to get the point across that there is nuance, the problem is a lot more complicated than “get a bigger server”, and that you need the freedom to operate.
If, on the other hand, you don’t have Trust, well, you’ve got much bigger problems to deal with, y’know?

(•) Unless you are a #CowboyDeveloper, in which case you already know everything, and this post is not for you.