Musings on Non-Mainstream Technology

Sometimes I resent my , but the number of times I'm glad I imposed it on myself is overwhelmingly greater.

Especially after a very long week which, as a sort of compensation for all the documentation, analysis, issue tracking and other quasi- pursuits, also involved (even if in passing) -related issues.

Which is very seldom, but surely worthy of some note. So, let's see if I can write this down in a way that will simultaneously:

  • allow me to remember what it was all about at a later date.
  • capture the essence (if not the form) of what has happened - and, hopefully, benefit the casual reader, who may find him/herself in a similar quandary in the future.
  • not leave even the tiniest hint of what gave rise to this particular musing (obviously).

The Crux Of The Matter

Being a user in a large corporate organization can be tough, but trust me on this one: Being a technically savvy user in such a place can be pretty trying, especially when trying to get across -specific issues that have bearing on things that you do every single day.

The Breakdown

There are three reasons for this, all of which are equally valid for most non-mainstream technology (just replace the with something else and change the first reason accordingly):

  1. The instant you mention the , people think of you as a casual computer user. With that bias in place, mentioning henceforth that you have used s for years and actually know how things are supposed to work and why gains you no leverage whatsoever. And that goes double if you explain, very slowly and patiently, that it's underneath and that you know what the current internals are supposed to do. Obviously, explaining that you've probably been coding in environments for longer than your listeners have used Windows will not help, but this week there was a specific occasion where I was sorely tempted to do so.
  2. People are not used to dealing with something that is fundamentally different. Different means unknown, and an unknown, in any organization that focuses on mainstream technology, is an un-quantified risk. Large organizations, in whatever form, have always needed help to cope with risk (again, in whatever form), and if you've been around as long as I have, you know the process is not easy, and invariably involves setting up or leveraging a long, convoluted (and ultimately somewhat off-target) process for dealing with it - in short, you treat the unknown with kid gloves and a hazmat suit.
  3. If they have had to deal with it in the past, they sought out advice from people they knew. Which means that you're not just dealing with the person before you - you're also dealing with an unseen quantity of unstated opinions and the underlying assumption that the previous "consultant" is the reference authority on the matter. Faced with this sort of situation, there is very little (if any) thing you can do but compromise - and even then, there are occasions when a partial solution is no solution at all...

Oh, and the absolutely best bit?

  • I don't have a at the office, nor have I used mine there for months now.

Epilogue

I guess this pretty much sums it up - I know it reads like my usual organizational analysis pieces, but yes, I needed to rationalize this and understand why it happened in this way.

The aspect of it is, as I said, mostly coincidental and in passing - my guess is that anything that steps out of the monoculture, in any large enough organization and in any market, probably faces pretty much the same issues.

That said, I'm off to enjoy a quiet weekend, free of any more considerations on the matter.