My notes on "The Trough of Despair"
My notes on The Trough of Despair
I like this article because it touches a problem that I'm seeing over and over again: short-sightedness. People want to see improvements and not decline even if the latter is often a requirement of the former.
The article describes it as:
Here’s the Sad Truth of Software Design—it always gets worse before it gets better.
It is the designer’s job to envision the desired state. It is also the designer’s job to design the shape of the curve, subject to reality’s annoying veto.
The key question for the designer is, “What would the system’s structure need to be so that <some feature> would be no harder to implement than necessary?”
First you have to get through the Trough of Despair
This is the period where everybody but the programmers are saying, “Why are we slowing down? We need to go faster, not slower.”
Architecting software is a series of decisions on tradeoffs: do I use this database that supports more complex queries or that other one that is better for scaling? Should this field be a single value or a list? Should we go with cookie authentication or JWTs?
These decisions are made based on requirements. But requirements change and now the architecture does not fit too well. What to do? Changing the architecture requires work that does not bring any additional features but makes it easier to incorporate the changes. This is captured in this quote:
First make the change easy, then make the easy change
- Kent Back
But that requires vision: yeah, we're gonna slow down for a bit, but it will be better in the future. What I see is usually just make it work by stretching the design a bit to fit into the current architecture. This is where things like "yeah, we don't support grouping invoices so we just use this special naming to do that" are coming from.
This is very nicely summarized in this HN comment:
People are vaguely good and competent, they leave systems in a locally-optimal state.
In general only changes that are "one step" are considered, and they allways leave things worse when you are currently in a locally optimal state.
A multi-step solution will require a stop in a lower-energy state on the way to a better one.
Monotonic-only improvement is the path to getting trapped. Take chances, make mistakes, and get messy.
