Making technical decisions (the results)

If you’d like to come to a fun workshop on choosing a web framework this Tuesday in Philadelphia, PA, it’s not too late to grab tickets! http://beacon.wharton.upenn.edu/webconf/

Last week, I asked if you’d share some experiences with making technical decisions. Here are a couple of my favorite responses.

The customer has to be right

One of my survey respondents pointed out that her clients often specify what tech they need for a project. This is probably common, even though I think the clients often should rather rely on the expert they’re hiring.

Eco-system

A developer at a major multinational corporation says that for him, the number one concern for a tool is “[t]ooling & the overall ecosystem. In other words, the health of the surrounding community, the extent to which there’s an existing open source culture within the community, and the extent to which the technology’s tools and libraries serve build, deployment, and development needs are taken into consideration”.

I really like the use of the word “eco-system” to encompass many of these factors — they can be difficult to quantify, but they must be evaluated.

Best tool for the job

Of course, I have a bias for this phrase, but got a few responses referencing it. My favorite being this from Tom Shawver of Leadnomics:

Best tool for the job. Scalability is great — *if* scalability is a primary concern. Speed is great — *if* speed is a primary concern. Repeat for team experience, ease of use, avoiding polyglot, etc.

If you’re using the same tool for every service in your stack, you’re probably letting bias play too big a role.

Well said.

If you haven’t yet shared your experiences (do these points resound with you? do you completely disagree?), please feel free, and hopefully see you on Tuesday!

Be Sociable, Share!

Tags: , , ,

One Response to “Making technical decisions (the results)”

  1. Owen July 25, 2013 at 12:42 pm #

    To riff a moment on “Best tool for the job”: This is a good point, although I like to point out to clients that they need not only the best tool for the job, but also the best craftsman with their tool. Sometimes the best tool for the job is not the tool suited for you to apply to the task. It’s possible that a Perl expert could craft a suitable, maintainable, efficient solution to a problem better than a Python novice, even if Python is arguably the better tool for the task.

    Being a polyglot can have its rewards, just as specializing in fewer languages can. I believe that you need to understand your limitations, both set by a client’s parameters and your own knowledge, which may lead to a conclusion that using “the best tool for the job” may not be your best solution for a particular project.

Leave a Reply