# Making reasonable technical decisions - a thread between innovation and stability - these are the kinds of principles that your staff engineers and architects already have deeply internalized, a lots of times it manifests as intuition. ### The paradox of choice - There so many choices. Deciding what to build and what to use it can be cognitively overwhelming because there are not a lot of established best practices that you can fall back on and there are incredibly few reliable narrators because most people are trying to sell you their own bleeding edge piece of crap ### Technology exists to serves your mission - we are not doing tech for the sake of doing tech - All code is liability, the best code is no code > The best part is no part. The best process is no process. It weighs nothing. Costs nothing ## Optimize globally, not locally - if you pick the perfect language/storage solution for every local problem, you will have an unmanageable mess. - Reuse solutions - Most startups fail not because of dumb tech stack but product market fit or whatever. How **resist software sprawl**? Can your exisiting tools solve the problem? Have some friction. Have a gating process for major new components: - **What is the relative gain?** Switching from ubuntu to redhat? Fuck that. If you wrote something python or ruby and are having concurrency issues and fundamentally cannot and should not solved and you need to use something like golang/c and gain multiple orders of magnitude of improvement that's a powerful argument. - It is a critical to a new feature which is **critical to the company mission**. - Manufacture friction if necessary - Don't micromanage outside critical path. People need the ability to experiment and have some fun. Let them play around. - Replacing a thing? Great. Define a timeline and **get rid of the old thing**. - Don't underestimate the operational overhead of bringing something new into your system. the cost of maintaining any solution over time vastly vastly outweighs the cost of developing it - running a database that you can solve all of your problems with, even if it only does it like 70-80% as well is way better than having to run 5/6 different storage types for all of the optimized use cases ## Choose boring technology - All software breaks. New software breaks a lot more. It's gonna break in unknown unknown ways. - Boring software rules the world. Boring means it's **failure mode is well understood**, rich ecosystem & library support - Corollary: early stage start ups have massive **risk tolerance** as you have fewer customers that'll be affected and way lower expectations. Use that risk! But **spend it on your core differentiators**. - But tech stack does matter: - How quickly you can move - How much tech debt you're going to accumulate - How happy the engineers on your team are - which has huge impact on hiring and retaining ## Spend your risk *tokens* on key differentiators - **Outsource** as many problems as you can. Just pay someone to run your CircleCI. Focus & spend your energy only on *problems that are core to your business and are key differentiators*. Limit these things to save engineering cycle. - Cost and pain of developing software is approximately zero compared to the operational cost of maintaining it over time. - At same time, **keep core problems/key differentiators in house** and be expert in those thing. Keep the expertise. ## Celebrate culture of removing parts - Culture can do ton of heavy lifting. Celebrate the engineers who remove code, deprecate and refactor as much as those who add futures - Patterns that you celebrate are the ones going to get repeated ## How to build a golden path and reverse software sprawl - Assemble a small council of trusted "senior engineers" - List of softwares fully supported by the org - Timeline to deprecate as many other tools as possible - After the cutoff date, establish a regular process for reviewing and incorporating feedback ### References https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/ https://www.oreilly.com/radar/a-young-ladys-illustrated-primer-to-technical-decision-making/ http://boringtechnology.club/ ---