Siderea

Dear employers (in the broadest possible sense) of technical experts (in the broadest possible sense,

One of the commonest experiences in working with a technical expert is that you have come up with some plan for something you want to do and your technical expert tells you that it -- or some part of it -- is actually a Bad Idea and that you shouldn't do it.

Sometimes, you'll ask your technical expert why it's such a bad idea, and they'll be able to tell you right off: "You said you want it to be blue. But if you build it with Java, none of the available databases support blue." or "You said you wanted it playable on gemshorn. Gemshorns only have a range of a ninth." And your response to this will, if you are a rational human being, consider this limitation and either change your requirements or give up the idea. (Predictively speaking, if you're an irrational human being, you will throw a temper tantrum of the "But I want it to be both made of asphalt and sold by McDonalds!" sort, and thereby make no friends.)

Sometimes, you'll find your technical expert will reply in something which sounds a lot like gibberish: "If you do that, your flux capacitor will not interchange with your neutrino combobulator while it's in over-ride mode." You don't know what a flux capacitor or a neutrino combobulator are (heck, you weren't aware you had such things), nor what it means for them to interchange or why you would want them to, nor in what circumstances over-ride mode would be used. But you gather, implicitly, that you're going to want your flux capacitor to interchange with your neutrino combobulator while it's in over-ride mode, and you will inquire further to investigate the parameters of the constraint: can we dispense with over-ride mode? Is there some other neutrino combobulator (or for that matter, flux capacitor) we should be using? And what will this cost us, any way?

And probably, if your technical expert is good at being a technical expert, you will discover that they're ahead of you and have already thought all these things through: they will patiently explain that you've sunk a heroic portion of your budget into these brands of flux capacitor and neutrino combobulator, and can't afford to replace them; and in any event they're the best ones for your purpose on the market; and over-ride mode is the basic default mode everyone runs in these days because MSIE12 will not operate in a 3 block radius around it if it doesn't. And, as above, either you'll abandon your idea, or announce, "Serves them right if they don't use Firefox! Off with over-ride! Banzai!"

But sometimes, your technical expert will say something like, "But that would be Bad". And when you press them, they "explain" by saying, at most, something that sounds like, "That would violate the principle of FirstKumquatsLast." If you're lucky. If they're less learned, they may simply wave their hands in frustration and say, "It just is. Bad. Don't do this."

There is an enormous temptation under these circumstances to say to yourself, "But I want it to be blue, and if they can't provide a Good Reason why it shouldn't be blue, then, dammit, I should get to have it blue!"

Here is the thing you need to understand:

In that scenario, what is overwhelmingly likely to be the Bad Thing -- and it is this which is so very hard to articulate -- is that by electing to do this Bad Thing now, you will be introducing more hard -- but as of yet unspecifiable -- trade-offs in the future.

Let me elaborate upon that: There are trade-offs in any project. Lots of them. Life is trade-offs. That's just how the world works. But trade-offs suck. Of course you want to have your cake and eat it too. The last thing you want is to add even more trade-offs to your project, artificially or accidentally. The last thing you want is to tie together the fates of things which really would otherwise be able to optimize individually.

It's easy to talk about a specific trade-off staring you in the face: "Either we can re-write it from scratch, or we can go to press with the previous version off the back-up tapes." "Either we hold the conference in the too-small hotel, or we risk not getting any hotel in time and having to cancel the conference."

It's much harder to talk about things which will cause future, unknown trade-offs. For example, you may decide you want to use two specific technologies in conjunction, and your technology expert says, "Bad Idea", because they know that those two technologies aren't typically used in conjunction in industry. They may not be able to tell you right now what trade-offs that will force, but they know by the sick feeling in the pit of their stomach that a whole bunch will crop up.

They may say things like, "It will limit our choice of third-party apps which inter-operate with both", which doesn't sound so dire -- until you discover neither love nor money will get you a wiki which can work with both, so now instead of having a free choice of which wiki would work best for your project, you have to choose which of these two system it's more important for your wiki to inter-operate with -- or whether you're going to write a connector (or wiki!) yourself to bridge the gap.

But in any event, that's just a guess and a hand-wave and an attempt at a convincing example. What your expert really knows is something like this: a whole lot of what makes something usable is its ecology of use -- the bigger and more complex, the better. All sorts of resources come out of that ecology. Putting oneself into a very tiny ecology of use drastically reduces available resources. And resource scarcity forces choices.

That sounds all terribly nebulous, doesn't it? What a vague and abstract thing to base a budget decision on! Especially if your expert only knows this in an inchoate, intuitive way, gleaned from their curriculum at the School of Hard Knocks, and which they cannot articulate to you in a meaningful fashion.

Yet that is exactly the source of all sorts of project-crippling -- and project-destroying -- circumstance. That is the road of good intentions.

Nor, to be clear, am I asserting simply the importance of keeping one's options open: The decision to keep one's options open may precisely be one of those Bad Ideas. As I just explained in the aforementioned 6hr meeting, "You may have as much flexibility as you are willing to pay for. No, you don't need a stable spec. Are you willing to invest the employee time -- and not just developer time -- in doing Agile right? Are you willing to invest in dynamically generated code?" Similarly, "Yes, you can decide not to decide what instruments you're instrumenting for, but that means you have to constrain yourself to the least common denominator of instrumental characteristics."

In every field of human expertise I have encountered, there would up being terms for principles and "best practices" to guide the prudent practitioner's choices. This is part of why you want a technical expert -- precisely to know these things. Because these ideas are heuristics for success.

Take for example "database normalization", a term that, unless you are a db geek, might as well be Sanskrit to you. It's exactly the sort of principle you might have your db expert say, "You don't want to do that, it would violate database normalization". There are reasons why one might want to make one's database store the data unnormalized. All those reasons -- pretty much -- are bad ones. They look convincing in the short term, starting with, "Normalizing multiples the number of tables, and each new table adds a week to the schedule/budget." And, yet, every single time I've used an inadequately normalized architecture, I have regretted it bitterly for one reason or another. Usually in about a year. Thus, the principle of normalizing one's data can be thought of as a heuristic to save one from oneself.

To maximize the utility of your technical expert's expertise to your project, you kinda need to just go with it. The point of having a technical expert is not just to know a lot of facts, but to be aware of pitfalls and approaches for minimizing pitfalls. You have them around to understand things you don't. And if you aren't going to rely on that understanding, if you're going to demand that you use your own understanding instead, if you're going to restrict yourself to the things you can understand, why do you even have them around?

And if you don't trust them to be able to exercise judgment for you, are they the right experts for you?