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. (See also related, but different "Second-System Effect")
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 and liabilities are not exposed, services will be used in expensive ways and eventually someone will want to replace the entire service.
If a project 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 a system without reducing energy will always be easier than reducing energy consumed.
Most software will get at most one major rewrite in its lifetime.