On choosing software by “what is best for the business”

When people are discussing what language/framework/library to use for something, the general criteria people talk about is “what best solves the business problem.”

• This criteria is used to justify rewriting backend services in Go, rather than sticking with Python. Or not.
• It’s used explain why you wrote a new CRUD app in node, even though you’re already using Ruby. Or not.
• It’s used to choose between frameworks like Watir or Capybara, even though they’re basically the same thing. Or not.
• It’s used to introduce superior programming patterns into legacy codebases. Or not.
• It’s used to introduce new unit test runners or libraries. Or not.

“Best solution for the business problem” is used to justify all manner of decisions that are risky and without worthwhile benefits. Likewise, it’s used to justify all manner of decisions that are restrictive and regressive.

I’m sorry to rat on my fellow developers but choosing by “what best solves the business problem” is a load of bullshit.

It’s much more honest to just admit that technology choices are made from a desire to work with a new technology, or because a technology is familiar.

• “We have approval to rewrite this service. I’m tired of working in dynamic languages, and I’d like to try Go.”
• “This is a small internal app, and I wanted to try node.”
• “I am familiar with Capybara, and will be writing most of the tests, so I’d like to use that.”
• “I am uncomfortable introducing a new programming pattern that I am unfamiliar with, even though it’s better.”
• “I don’t like using this library, and the one I do like can live side-by-side, so I’d like to add it.”

I actually don’t have a problem with deciding this way. In fact, I think it’s a good thing! I want to keep employees happy. But it’s important to be clear about how you expect a codebase and culture to evolve (encourage or discourage change). I want to understand why and how we actually make decisions, so we can get better. Honest discussion leaves fewer loose ends, and less surface area for future criticism.