A lot of finance terms have transferred into the software lexicon. Terms like investment and technical debt. Investment in the software sense is the act of spending resources over time to build up platforms and applications around a particular language, framework, or ecosystem. Perhaps it makes sense to define divestment as well. Divestment would be the expenditure of resources in the opposite direction. Spending resources to move away from or off of ecosystems, platforms, etc. which have become an obstacle to further evolution.
By proposing this term, I'm really hoping that it sticks and becomes a normal part of our daily language about software. Because then bad behavior that is hurting our users will stop.
What bad behavior you ask?
Sunk cost / escalation of commitment
Recently a photoshopped Dilbert has been making the rounds online and in conference presentations.
I saw it originally here:
Liquid error: internal
Like this tweeter, I still have no idea who the genius is who made this comic, but congratulations to them so succinctly summarizing a modern problem that I'm sure we all resonate with.
Many times, software teams feel locked in to their past choices and are unwilling to divest. Rather than evolve and become more nimble, they dig in and double down. They have classic "escalation of commitment:"
Escalation of commitment is a human behavior pattern in which an individual or group facing increasingly negative outcomes from a decision, action, or investment nevertheless continues the behavior instead of altering course. The actor maintains behaviors that are irrational, but align with previous decisions and actions.[1]
Economists and behavioral scientists use a related term, sunk-cost fallacy, to describe the justification of increased investment of money or effort in a decision, based on the cumulative prior investment ("sunk cost") despite new evidence suggesting that the future cost of continuing the behavior outweighs the expected benefit.
Source: Wikipedia
Buckling under the weight of debt
I believe that software teams often combine "escalation of commitment" behavior with "shiny object syndrome" or "fear of missing out."
This is exactly what is happening in the Dilbert comic above. Everyone has their applications in the cloud and every software team wants their application there, too. But they aren't willing to divest from pets not cattle thinking and they still run their app like an on-prem one.
The result?
Throwing technologies (Kubernetes) at the problem indiscriminately, thus creating more problems.
(To be clear, I'm criticizing the people who use the technology wrong, not the technology.)
The Divestment Habit
Instead, a software team frequently practicing the habit of divestment would recognize an opportunity to divest from past decisions and invest in new ones, ones which will position their application for greater service to their users.
Divestment should just be part of how top software teams work. And since they practice using this muscle all the time, they actually do their work just as fast as other teams who always put their work right on top of whatever exists already.
As an individual, you should see it as your job to steadily refactor the code you touch so that it uses better practices, libraries, dependencies, or whatever. Don't ask for time to "refactor." Practice refactoring enough that its an essential, and completely routine, part of how you work, not requiring a special ask.
Show value through divestment
Divestment is about showing value--pivoting away from things that are no longer bringing value to things that will. In that way, it is in reality no different than investment. It's simply a little bit of work now that will result in a greater outcome later.
But don't divest as a reaction to FOMO or "shiny object syndrome." Really think about the value each situation can bring. Engineers will always spend their time somewhere. Spend time on valuable things. I do believe that divesting from the past needs to happen in the evolution of any piece of software, and I think our industry in general has not grappled with the idea that divestment is just part of life. There are too many engineers still who want to build up an application and then coast. People who say things like:
Java 6 is good enough. Python 2 is fine. I built a lot of ASP.net 2.0 apps that are still in production, so why bother with something newer?
I believe there needs to be a common goal acknowledged by everyone in a software team: that evolution needs to happen. That they are committed to always pushing forward.
Only then can we really advance.
Top comments (0)