Space X Raptor Engines
"Keep it simple."
I've said this to engineers and designers more times than I can count. It's good advice, but I've come to appreciate how difficult it is to follow, especially when you're building something that hasn't existed before.
Simplicity is often something you discover after spending considerable time exploring complexity. You try things, add things, make mistakes, and eventually develop enough understanding to recognize what can be eliminated. Sometimes the most complicated version of a product is an important step toward creating the simplest one.
Consider SpaceX's Raptor rocket engines. Look at the progression from Raptor 1 to Raptor 3. The early engine is a jungle of pipes, fittings, and external components. Raptor 3 looks almost impossibly clean by comparison. Much of that plumbing has been integrated into the engine itself, eliminating external parts while improving the overall design.
Nobody could have drawn Raptor 3 on a whiteboard at the beginning and handed it to the engineering team. The knowledge required to build it came from years of designing, testing, breaking things, and making improvements. The apparent simplicity of Raptor 3 conceals an extraordinary amount of engineering complexity.
Microsoft Word provides another example. (Cue the haters.)
Over the years, Word accumulated an enormous collection of features, menus, toolbars, and options. By the early 2000s, Microsoft had a peculiar problem: people were requesting features the software already had. They simply couldn't find them.
The Ribbon interface, introduced in 2007, was an attempt to make that accumulated functionality more accessible. Microsoft didn't have to throw away decades of capability. It had to develop a better understanding of how people worked and reorganize the experience around that understanding. Whether you love or hate the Ribbon, the exercise illustrates how much work can go into making a complicated product easier to use.
I've watched engineering teams struggle with this for years. We want them to explore possibilities, solve difficult problems, and accommodate the peculiar ways customers actually use our products. At the same time, we're telling them to keep everything simple. Those instructions can be at odds with one another, particularly early in development.
There is a legitimate danger in adding too much, of course. Every new feature creates something else to maintain, explain, and support. But there is also a danger in demanding simplicity before the team understands the problem. You can end up eliminating something important simply because you haven't yet discovered why it matters.
A better approach is to allow some messiness during exploration while remaining relentless about simplification as understanding improves. Build enough to learn. Pay attention to what works. Find the parts that can be combined, hidden, automated, or removed. Be willing to throw away work that helped you arrive at a better solution.
I've come to think that "keep it simple" is a reasonable destination but a lousy set of directions. The hard part is knowing when you've learned enough to begin taking things away.