Thursday, February 17, 2011

Choosing the Highway

Some decisions when building a product are outside of your control. Some are fully in your control. Today let's take a driving trip. We don't get to pick our destination; that decision is out of our control. We do get to choose how we get there.

As we pick our route, we make choices. Some choices are small, like what radio station to listen to, or which side street to take. Some choices, however, are large, like which highway to take. They have a vast effect on our project, I mean, road trip.

Throughout a project, we make small decisions and we make highway decisions. Small decisions are things like a variable naming convention that don't have much effect on the end use of the product. Highway decisions are things like which language to use or whether to write object oriented code or not. Small decisions are the ones you should make quickly and easily because their effect is small. Highway decisions should be taken more seriously and are something he team should decide together and explicitly.

Choosing the right highway has a few factors. Sometimes both highways get you there but one is faster than the other. I used to commute from Cupertino, California to San Francisco every day. I could choose from two highways that would get me there: highway 280 or highway 101. Both will get you to the same city, but 280 was a lot faster and prettier, too. Choosing a language is often like this: both will get you there but one will do so more quickly and will be prettier along the way.

Other times, choosing the wrong highway will prevent you from reaching your destination; you'll have to go back almost to the start and pick a different highway to get there. Imagine if you accidentally got on an east-west highway in Nevada when you really wanted to go north - it's a long way between exits!

I worked on a product once that was an installable Windows application. We'd chosen our highway - the thick client PC program highway. A few years later, the big boss came in and announced that we were now a Web 2.0 company. The problem, of course, is that the web-based application highway was waaaaaaaayyy back in our rear-view mirror. We had to go all the way back to the beginning before we could even start trying to build a web client. It was ugly code, a buggy program, and in the end the company didn't make it.

So how do you know when you're about to make a highway decision? Well, some entrance ramps are pretty clearly marked. Your language, your overall architecture: those are pretty obviously highway decisions. Other times you don't really know you're going to get on a highway until you're there, and that goes for decisions, too. Choosing a library doesn't always feel like a highway decision, until you're locked in. To see if you're getting on a highway, ask yourself:
  • How easily can I change this decision if I want to?
  • Will the end user feel an effect as a result of this decision?
If the answers are that it's not easy to change and that the end user will feel an effect, then you've got a highway decision.
As I think back over software projects, most of my choices were small and didn't matter much to the product as a whole. Left lane versus right lane; camel case variables versus underscore-delimited variables - no big deal. Some of my choices where highway choices. Java versus Ruby, web-based versus thick client, deploy on Windows versus Linux. Those choices mattered three years later when I thought back on them.

For most decisions, just make them and go. But when it's a highway decision, take a look at where you're going and how you want to get there - and only then make a decision.

No comments:

Post a Comment