Choosing a Technology: You’re Asking the Wrong Question

Mar 27 2013

When making a choice in the tech world there are two wide-spread approaches: “What’s better, X or Y?” and “Should I use xyz?”. The “or” debate is always an entertaining topic usually ending in an absurdly hilarious flame war. The “Should I use xyz?” is a subtler, more prevalent question in the tech community leading to an extensive amount of discourse. Fairly rational, usually with some good insight, but still a time consuming task. I’ve fallen victim to both approaches when exploring a technology decision. What I realized is I’m asking the wrong question. There are only two things I should ask:

1) What problem do I need to a solve?

2) How do I want to solve it?

Once I take this approach I have an opinionated basis for decision-making and I have a clear direction in how to make that decision. Frameworks–web or javascript–are excellent examples on taking this approach. Most of these frameworks were born on the simple premise of solving a problem in an opinionated way. Backbone takes a bare-bones approach to a front-end, event-driven structure; Ember offers a robust, “things just happen” framework. Sinatra and co. offers an http-first approach to development. Rails and variants are opinionated in web application structure. Do you agree with that approach? Yes, excellent! No? Find something else or roll your own.

Don’t know the answer? That’s okay too. Most beginners want to make the “right” choice on what to learn. But the thing is there is no “right” answer. For a beginner choosing python vs. ruby vs. php vs scala wastes effort. Just build something using something: you’ll soon develop your own opinions, with “how easy is this to learn” probably the first. Next, when your rails codebase is out of control and you’re drowning in method_missing issues maybe you’ll want a more granular, service-orientated approach and the type-safety of Scala. Maybe not… But you’ll have a valid problem to solve and a reasonable opinion to go with it.

I suggest reading Andrew Alexeev’s reason on why he built NGINX and Poul-Henning Kamp’s rationale on how you write a modern application. Like so many others these incredible open-source systems were born from a problem and the way someone wanted it solved. But those systems didn’t happen overnight and the authors didn’t start from scratch. They spent years encountering, learning, and dealing with problems in their respective spaces. They knew the problem domain well, they knew how they wanted the problem solved, and they solved it.

So put your choice in a context and don’t sweat the details which are irrelevant to the task at hand. When you need to know those details you’ll know them, and when you hit problems you’ll know how you want them solved.