economy debt and software tech debt
An example how software follows not just the structure of the organization its built in (Conway's law), but also the conditions of the general economy.
The clients I work for enjoy accumulating extreme amounts of technical debt for all kinds of reasons. This leads to an environment where having an outage is not some exceptional situation, but the norm. As I'm working through some of the issues, I noticed how similar it is to the economy on a global scale.
Some debt can be positive if managed properly. Too much debt becomes overwhelming and, in the end, destroys growth, income and the path to positive outcomes.
The general economy is accumulating so much debt that a "tree shake" will force a lot of companies into defaults or mass layoffs. COVID caused a big shake and employment won't recover for years. Another tree shake can happen if price of credit rises a bit and the overextended companies can't refinance themselves.
How to spot such a company? It has become a new normal for a "growth" company to operate without any profits. They overspend on marketing; hire too many people, which don't do that much or take on too many projects assuming they'll be able to hire all the staff required; they order too much inventory that can't be used productively; overinvest on questionable projects with extremely uncertain future.
Business isn't made to be resilient, or can't afford it, or refuses to afford it, and the cost is passed on to employees that might lose their jobs. And the consistent government bailouts are only reinforcing the behavior.
Software built quick and dirty has tech debt waiting to be paid off:
- by cleaning up the architecture
- documenting the code and requirements
- adding tests
- creating a proper development environment
- extensive monitoring
- automated deployments that support rollbacks
- incorporate engineering feedback into the management process
Instead of all those things, the business expands the code with more features, because that's what brings more money in the end. This makes the job of the engineers exponentially harder, because they can't experiment with the code freely, nor hold all the complexity in their heads. So more and more qualified people are needed. The layoffs start, because people are failing to deliver on projected goals. Firing the initial developers loses the domain specific knowledge of all the magic that keeps together the project - the underlying architecture, the rough edges, the important requirements, how to deploy, how to test things without causing outages. The newly hired people now have an even harder problem, because they lack the accumulated knowledge, they have crazy deadlines, they are unfamiliar with the business process as a whole etc etc.
Interestingly, in either case, it seems nobody learns from the past. Overextending has been the norm in recent history. In fact there's this advice floating around: being negative (safe) sounds smart; being positive (taking risk) makes money. Generic mental shortcuts like that work until they don't. Try to be aware of your surroundings, understand and manage your risk exposure, because if the fundamentals change, you are in trouble.