Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

On Choosing Software by "What is Best for the Business"

DZone's Guide to

On Choosing Software by "What is Best for the Business"

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

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.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}