I have the same experience, and I agree that simplicity leads to success. The more things software can do, the harder it is to reason about what it's supposed t

I have the same experience, and I agree that simplicity leads to success. The more things software can do, the harder it is to reason about what it's supposed to do. It's very much the IQ bell curve meme: junior developers only solve the problem at hand, mid-level developers build powerful, but complex frameworks which can solve the problem at hand but also potential future problems, and senior "X10" developers only solve the problem at hand. > There are times during the development of any project where one might be tempted to hack around an issue, or commit the ugly code that seems to work. These are the rough edges that inheritors of a codebase use as evidence that a blank slate would be preferable. Yes, one thing I've learned is to never underestimate the power of inertia in a codebase. When adding functionality, 99% of developers will go for the path of least resistance, which is mimicking whatever patterns already exist. To loop back to the article, this is often due to lack of full understanding; the default assumption is that because something is written in a certain way, that it's the best way. This isn't true; it may not even be the correct way! But copying what already exists has an element of safety built into it, without needing to spend the effort to deeply understand existing code (which tends to be developers' least favorite activity). So if you put in an ugly hack, or have a code structure which doesn't make sense, expect that to persist for years, or decades.