Are you a Technology Bigot?

A couple of days ago, I was speaking with a friend who spent a good portion of the conversation trying to convince me that I should become proficient with a particular computer language. It would seem, based on this discussion, that this particular language is FAR superior to any other language that has ever been invented. It has all the features of this other language, and only the GOOD features of this other language, and not the baggage of THAT OTHER language, and, and, and it does all this neat stuff, and… It's just so cool I simply wouldn't believe it.

I have to admit this conversation made me chuckle a bit. While the information was certainly useful and the banter about "which peanut butter tastes more like peanuts" kind of discussion is always entertaining to some degree, what he didn't know was that I had spent a greater part of the day in similar discussions about other languages and platforms. Which database is better? Which language is better? Which operating system is better? Which development environment is better? Which technique is better? Considering that a good deal of time seems to be spent going back-and-forth over these very issues, I've decided to take a departure from my favorite topic (that is, our Aspen database project) and attempt to answer these questions once and for all.

Sounds pretentious, doesn't it? How can one guy purport to provide an answer to these age-old debates? Forgive me if I offend any delicate sensibilities, but the answer has always been right under our noses...


What's the best database for any given project? Listen to the person who will use the information. What's the best language? Again, listen to the person who has the problem to be solved. With either of the preceding questions, and the numerous questions that haven't been specifically mentioned, the answer is generally hidden in a wealth of subject-matter knowledge waiting to be mined through intent, focused listening.

"Hey now," I can hear you say, "my customer knows nothing about languages or IDEs or platforms or operating systems. How can listening to my customer help me select the best language for a project?"

While this may very well be true, the fact remains that your customer has a certain level of subject-matter expertise. He or she holds the keys to the problem that they want you to solve. By understanding their specific problem from their perspective, and comparing this understanding to your understanding of various technical options, you arrive at a better position to select the most appropriate tools for the task.

Unfortunately, this kind of listening is becoming more and more rare. Instead, the technology community at large seems to be mired in a form of "technology bigotry," where the only solution to a given problem is whatever technology happens to be en vogue at the time. Perhaps you've heard comments like these? (Substitute any technology in place of the blank, i.e. Java, Unix, or even Pick.)

  • "We're a ________ shop."
  • "______________ has a perfect solution to any problem."
  • "______________ is the only REAL (database | language | operating system | et al)."

and my personal favorite:

  • "Real programmers never use ______________."

This kind of thinking tends to fall under the category of the old cliché: When all you have is a hammer, everything looks like a nail. Problem is, not everything is a nail. Occasionally we need wrenches, sockets, and screwdrivers to get the job done. The same holds true in the software world. Everything doesn't always fit into a nice little box that can be solved by one and only one option; sometimes a task calls for different languages, databases, environments, and maybe even a dip into a new operating system. The trick, if there is one, is simply to have enough tools to make an informed choice possible.

This is where it can get dicey. While I can't speak for the community at large, I suspect that most people in the business of creating software are pretty busy — busy enough to where there's not a lot of time available for exploring new options.

Then there's the whole cost factor. Learning new options requires some kind of investment; whether time, money, or both. And: Is there really a benefit to knowing the latest whiz-bang technology when you may or may not actually use it?

In answer to that question, it has been my experience that it is ABSOLUTELY beneficial to continue to learn new things, even if you may not ever use them. Exploring new options almost always provides new ways of looking at problems and situations. Who, after learning something new, hasn't looked at things just a little a bit differently? It is these perspective shifts — some moderate, some dramatic — that provide the foundation for making better technology choices in the future.

Sometimes when we learn new things, it provides evidence to support what you may already believe. How many of us (and you don't have to raise your hand) have made a decision against a particular technology or product simply because we heard from somewhere that it had this problem or that problem? Did you personally experience that problem? Did your source happen to tell you that, while this or that problem may exist, there was this or that way around the problem? A solution that was better for a variety of reasons?

No, of course not. Technology bigotry works like that; in each generation the prejudice grows stronger and stronger while the evidence to support it becomes less and less compelling to a point where fact and fiction become indistinguishable. At this point, the solution providers — that is, each of us — are on perilous ground. The discounted technology may be just what the customer needs, but we're too blinded by prejudice to see it for what it could be in that context. Perhaps your original technology choice was the best one, but how can you know for certain unless you've personally experienced other options?

In closing, my point is this: simply try to interject some reason into the ongoing debates of "best" anything. Defining "best" without defining a context is like saying yellow is the best color. Perhaps for some uses it is. For others, it's not. The same is true for technology; there can never be one best anything without considering the context. Listen to your customer. Have a well-equipped arsenal of options from which to choose. Use all this information to make the best choice.

After all, the software business isn't really about creating software; it's about solving problems.


Mar/Apr 2015