I think he is missing a major problem:<p>> We enter solution mode and start thinking about solutions for those flaws and how we'd design those items. We are so intelligent. We'd make it better, wouldn't we?<p>> However, when we do this kind of analysis, we may miss the context. Maybe the folks responsible for the design had constraints. It can be a tight timeline, low-quality, or too-expensive materials. Sometimes, it's a waterfall process, and it's too late or too expensive to fix it.<p>The second paragraph gives plausible reasons why the product might be bad/overly complex: maybe changing requirements interfered with waterfall process? Or maybe they had a hidden design constraint, like "can run on shared hosting machine without root access" or "our CEO insisted we use Mongo"?<p>But if those were the reason, then yes, we could make a much better version, possibly even during the weekend. Because we know our requirements, and we no longer care about ancient hosting, and our CEO is sane and allows us to use whatever technologies make sense for the project. So our solution will be objectively better: smaller, easier to maintain, faster and more feature-full.<p>I've seen a great example of this in the past: there was a certain component that was crashy and very hard to maintain. And some day, one of the developers looked at it and tried to figure out why it was so complex for the things it did. Turns out it was built to outdated requirements which no longer applied to us, like "LISP bindings", "big-endian machines", "C89 only", and "no external libraries". They rewrote it from scratch in a week and the new version was vastly simpler and much more stable. The conclusion was simple: sometimes the software is complex because of 2nd order effect.. but sometimes it is complex for no good reason.
This is a painful lesson you learn with time: "It's easy to oversimplify problems and try new, leaner technologies that optimize for our use cases. However, when scaling it to the rest of the organization, we start to see the dragons. People that didn't build their software the right way. Entire tech stacks depending on libraries that teams can't update due to reasons™. Quickly, we start realizing that our lean way of doing things may not serve most situations." -- It's a costly one, as it affects people (how we make decisions) and code (what needs to be refactored now). Excellent writing by João Alves.