Software Engneering
Forcing Functions -there are some things you can do to force issues up to the surface.
Dig out an old or cheap phone and try to run your app on it. Any major performance bottlenecks will suddenly become obvious
Pretend you’re a new developer in the team1. Delete the project from your development machine, clone the source code and set it up from scratch. Gaps in the Readme file and outdated setup scripts will soon become obvious
Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious
Port a few screens from your front-end app to a different platform. For example, write a command-line interface that reuses the business and data layers untouched. “Platform-agnostic” parts of the architecture might soon be shown up as anything-but
Start releasing beta versions of your mobile app every week. The painful parts of your monthly release process will start to become less painful
Put your software into the hands of a real user without telling them how to use it. Then carefully watch how they actually use it
Software Peter principle - The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.
Zawinski's law of software envelopment - (on feature creap) Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Evidence-based Software Engineering - http://www.knosof.co.uk/ESEUR/
DRY, or Don't Repeat Yourself
Don't Repeat Yourself is a tradeoff - https://orbifold.xyz/dry-trade-off.html (HN)
Pros and cons of DRY code https://qvault.io/2021/01/25/the-pros-and-cons-of-dry-code/ - "one place to change a fact". things that tend to change together should be closer together.
