Originally published in the Open Systems Database Association Newsletter, Spring 2001
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 up to that point 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 bantering these very points, 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 ages-old debates? Forgive me if I offend any delicate sensibilities, but the answer has always been right under our noses…
Listen.
What’s the best database for a 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 any 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 and holds the keys to the problem that he or she wants you to solve. By understanding the 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 options 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, everything isn’t a nail, and occasionally one needs 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.
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 to be exploring new options. And 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 everything 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 learning new things simply 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 that was better for a variety of reasons? No, of course not. Technology bigotry works like that; 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 provider – that is, each of us – are on perilous ground; the discounted technology may be just what the customer needs, and we’re too blinded by prejudice to see it for what it could be in that context. In a phrase, 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 of all this is to simply try to interject some reason into the ongoing debates of “best” anything. Fact is, defining “best” without defining a context is like saying yellow is the best color. Perhaps for some 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.