/ Sahil Muthoo

What are the tradeoffs?

Two-pan balance weight
Two-pan balance weight



a balance achieved between two desirable but incompatible features; a compromise.

a giving up of one thing in return for another.

Software is a collection of tradeoffs; made one line, one function, one feature at a time. If the tradeoffs we make match up with the ones our customers are willing to make, the software wins. Otherwise, we end up with the software crisis.

We as programmers constantly struggle with tradeoffs. We make choices to the best of our abilities. It’s time to share that burden.

I suggest that we become deliberate about tradeoffs. If you do user stories, include a tradeoffs section in each story. While designing on a white board, let’s constantly ask, "What are the tradeoffs?". "Do these tradeoffs align with the ones our customers are willing to make?".

link Tradeoffs and stakeholders

Stakeholders are often times the best judges of a bargain. If we’re seduced by new-shiny™, it’s good to ask another stakeholder. For example, event-driven-eventually-consistent-microservices sound so sexy. Asking a stakeholder if they’re OK with eventually consistent transactions should be enough to break our stupor.

If businesses ask us to finish work in unreasonable time, we should make them aware of the tradeoff. Work completed in a hurry will build technical debt. Debt that must be paid in full when it’s due.

link All tradeoffs are not made equal

Adding a dependency is a tradeoff. We tradeoff complete understanding and control of our code in exchange for time. In recent times, the left-pad fiasco from the NodeJS community is a shining example. For the uninitiated, left-pad was a NodeJS library that left-padded strings. The library was yanked by the author for political reasons leaving several broken projects in its wake.

The programmers who used left-pad gave up control of their projects for a function of a few lines. This was a poor bargain. They gave up control for very little, if any, time. A programmer mindful of tradeoffs will always be tuned towards such problems. They’re deeply aware of the costs and constantly looking for the value.

On the other hand, libraries are abstractions. Abstractions are the root of all progress. Without such powerful abstractions we would still be twiddling bits on pieces of perforated paper. The Unity game engine lets programmers build games that run on the vast majority mobiles, PCs and consoles. How’s that for an abstraction? A lot of programmers trade-off a lot, including money, to use Unity.

All tradeoffs are not made equal. Each time we add a dependency, use a library, introduce a framework we must question the value. The bargain must be solid.

link Documenting tradeoffs

Documenting tradeoffs are a good way to make the decision deliberate. Let's say you need to decide on a full-text search engine. After evaluating Elasticsearch and PostgreSQL you conclude that PostgreSQL is a better fit for your use case. Maybe you already have a robust PostgreSQL deployment and limited full-text search needs.

It's good to document why you chose Postgres over Elasticsearch. You could put it in the user story or epic. Be sure to mention that you're aware of missing full-text search features in Postgres but you've traded that off for easier operations.

If your software lives long enough, a time will come when tradeoffs will need to be re-evaluated. At such time, a record of past decisions will help greatly.

link Architecture decision records and tradeoffs

It's becoming more common to capture Architectural decisions in the log-book style format of an ADR. The linked blog post doesn't make an explicit mention of tradeoffs. However, I feel an architectural decision must contain some tradeoffs that ought to be documented. If we document a tradeoff today, we stand a better chance of convicing a stakeholder or a fellow programmer tomorrow.

I hope I've managed to convince you that we make tradeoffs all the time. All I request is let's be more deliberate about them. It's work, but I feel it pays off in the long run.

I would love to hear your thoughts, please contact me via the interwebz using the links below. Cheers!