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.
If a team is given a proxy metric that is easier to hit than the long-term goal, they will learn to ignore true success.
Any piece of software that does not expose its inner workings (logs, metrics, and errors) will silently accumulate drift from needs, ensuring its failure will be sudden and catastrophic.
Once a project has a dedicated server, maintenance budget, and or an assigned owner, it will remain running forever, draining time, money, and engineering time.
Any team that becomes optimized for a single task will become the single greatest resistance to the system’s eventual necessary evolution.
Any dependency will over time consume more engineering time to manage its updates, vulnerabilities, and breakage than the original time saved.