Balance: Why Binary Decisions Are Often Suboptimal in Software Engineering

As software engineers, we tend to make rather binary decisions, to favour clear-cut outcomes and black-or-white choices. I guess it’s in our nature.

This applies when choosing technology and architecture, but it also extends to how we like to organise ourselves and our projects.

  • We pick a architecture or an one.
  • We favour developers or we see the value in .
  • We prefer teams/squads or we go for cross-team .

We tend to pick one extreme or another and to stick with it.

The problem is, even in a field as precise as software engineering, these binary decisions rarely tend to be optimal.

Particularly for topics such as architecture or team dynamics, there is often a sweet spot between the extremes; a balance of the two that works much better in some scenarios, but we have to be open to that possibility and not restrict our search to binary, clear-cut answers.

  • Serverless can be ideal… long-running computations or where traffic is ramped up enough that an instance-based deployment becomes cheaper.
  • Full-stack developers who can work on any part of a use case are a sensible choice… we need them to cover significant complexity & depth as well as the breadth of our stack, such as on a project with a very involved UI, a complex architecture or heavy backend computation.
  • Autonomous teams can move quickly and innovate… we may want to introduce some standardisation between their approaches to leverage reuse or to keep control of an overly-diverse tech stack.

What I’m saying is that when we consider the practicalities of many software engineering situations, a binary “either-or” answer is often suboptimal and a more balanced hybrid approach might actually hit the spot. The challenge is to entertain that balance rather than always looking for what we, as engineers, feel is a cleaner binary outcome.

The answer might not be , but .

The world, including software engineering, perhaps isn’t always as binary as we’d like it to be.

Building software to solve hard problems (Software Engineer / Lead / Manager) — Opinions are my own.

Building software to solve hard problems (Software Engineer / Lead / Manager) — Opinions are my own.