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

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:

Published at DZone with permission of Rob Galanakis, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}