The complexity unlearning curve
A couple weeks ago in a his news videos on YouTube, Sean Allen highlighted a tweet from @flaviocopes that plotted a developer’s journey as they choose between simple and complex software architectures. The tweet included the following image:
Before reading the labels in the chart, I looked at it and thought: “Hey this is a Gartner Hype Cycle curve!” But it isn’t—or maybe it is?
On reading more closely, it immediately resonated with me. I can recall being enamored with elegant but complex software architectures earlier in my career. I assumed complex tooling would enable me to build much better products.
Eventually, after countless hours learning to use complex architectures (and more countless hours chasing bugs hidden in those layers of complexity), I concluded that complexity in software is a double-edged sword to be wielded with great care.
Not that complex software patterns have no place at all—there certainly are places for complex architectures. Some problems are complex. But for the 90% of software built to solve some concrete problem, experience shows that simpler is more maintainable. Simpler is easier to test. Simpler is easier to troubleshoot and turn over to the next developer to extend and maintain.
Recommended by LinkedIn
Today I think I view software engineering complexity in the way mechanical engineering considers design complexity.
Making something simple and maintainable is actually harder than adding complexity. There’s unappreciated skill in making simple things.
Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. — Steve Jobs
This post was originally published at www.cuvenx.com.
It's a great design philosophy. I used your calculator code with my ESP32 today to write an iOS app and loved the way you broke things down. When I tried to use the Adafruit tutorial or internal Apple code it was too abstracted to understand. Thank you!