Software Laws
Or really, observations
When every developer is committing to the same branch with no pre-commit checks the odds that a commit will break the build increases as more developers contribute to the project (Application of Poisson limit theorem).
If the release cadence for software is slower than it takes to create a minimal competitor the software will have competition that is stronger than it would like. (The r value is decreasing in a Logistics Map and application of cash flow principles).
If the ownership of a piece of software changes, the odds of the software being re-written increases dramatically.
An error or log message that is only a static string will eventually get a change request to include dynamic information.
As long as costs are not exposed, services will be used in expensive ways and eventually someone will want to replace the entire service.
If a refactor/rewrite/etc can't be finished in less than 6 months it will probably never be finished because some new more important project will come along.
When inheriting code, removing state is never the wrong first approach. Or when writing new code all things being equal choosing to do it in a functional manner is always the right choice.
Increasing the value produced from an amount of energy will always be easier than reducing energy consumed because a system that consumes energy will continue to consume that level of energy as long as it can. For example: an org that grows in size to undertake a challenge will later find random projects rather than shrink, in worse case only reducing in size perhaps by a layoff. Software that uses exuberant amount of system resources will continue to operate that way until a forced to improve perhaps by a competitor.