Balance: Why Binary Decisions Are Often Suboptimal in Software Engineering

Photo by NordWood Themes on Unsplash

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 serverless architecture or an instance-based one.
• We favour full-stack developers or we see the value in specialisation.
• We prefer autonomous teams/squads or we go for cross-team coordination.

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… except for 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… until 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… but 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 “A or B”, but “mainly A, with some B”.

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