Similar-but-different is a bad thing in most (but not all) contexts I'm involved with. ## When Similar-but-Different is Bad - **[[Enterprise Architecture]]** - in most cases you don't want to have similar-but-different processes, data, applications, and technologies. By definition, if they are similar, they accomplish similar tasks (their value proposition overlaps), but their [[Overhead]] likely does *not* overlap. In many cases having 2 of something is actively *worse* than having one. [[Data Governance]] comes to mind. - **Personal-sized EA-like decisions** - having multiple subscriptions for cloud storage doesn't really make for a meaningful improvement over having just one... but it raises the price you're paying for storing things in the cloud. - **Productivity Stacks** - if you're [[Project Lists|managing projects]] in similar-but-different places, you'll have a harder time getting a grasp on all thing things on your plate. You might miss [[Deadlines and "Do" Dates|deadlines]] from one project management system because you're spending your time on projects from the other. ## When Similar-but-Different is Good - **Weightlifting** - doing exclusively one type of move means you'll be under-training specific little muscle groups. For example [[Bench Press]] and [[Incline Bench Press]] are very *similar*, but also slightly different. Incline focuses more on higher pectorals, whereas flat bench focuses on more on the lower ones. - **Intentional Redundancy** - if you're [[Plan for Failure|planning for failure]], having similar-but-independent mechanisms to achieve the same result is a good thing. Your alarm might fail to go off, but the wake-up call came through. **** # More ## Source - myself