"System Design" Rules That Continue To Haunt Me

You think I'd have learned by now, but the following rules are ones that always hit me upside the head, even though I know better!
I'm not saying that these rules are inviolable (this is software after all!). It's just that if you violate the rule, be sure to have an excellent reason involved, and even then, check again, and then document it. The documentation, in particular, will help you remind yourself what a butthead you are…

1. Make Scaling intrinsic to the design. It doesn't matter whether this means autoscale groups, k8s, or auto-instantiation of domain objects, the point here is that scale - at all levels - can not, and should not, be something that you bolt on afterwards.

2. Make Deployment a first class citizen. Ideally, a merge into master should trigger a production deployment. And yes, this implies code coverage, comprehensive testing, toolchains, and everything else you've (hopefully!) read about. Maybe you're not there yet, but you really, really, should be focusing on getting there.

3. Don't reinvent the wheel. It doesn't matter how clever you are, you don't need to write your own queuing system. Or network stack. Or deployment engine. Seriously, Just…Don't…Go…There.

4. Remember Conway's law. You must structure your teams appropriate to your product. If you don't, you will end up with components that resemble your team, whether you wanted to or not.

5. Shit Happens, be prepared. Oh yes, it does, and in the most unexpected of ways, and from directions that you won't (or can't!) expect. Instrument the heck out of everything, and let Observability be your mantra - it won't stop shit from happening, but when it does, at the very least you'll be prepared to deal with it.