| So this article concludes that starting with a certain project size, over-engineered code is easier to work with than under-engineered code, and scales well when the projects grows (even "linear with the size"). But what this article is actually about is about entanglement of individual parts. Under-engineered implies spaghetti code with lots of entanglement. Over-engineered code does have the minimum needed amount of entanglement. Of course this is right on the topic of entanglement. But this is not so much my understanding of the terms over-engineered vs under-engineered. I understand over-engineered as having too much abstractions. And those can turn out to be the wrong abstractions when they are actually used, which then requires more work to refactor this. I understand under-engineered as having too little abstractions, and having build in some assumptions which might hold for one use case but not anymore for others. This can also require some effort to fix this. In practice, this is also a continuum, and you might even have both things mixed. And when actually writing some new code, it is often hard to know the right amount of complexity. This is why the overall quality greatly improves when you do a couple of iterations of rewrites from scratch. Because you keep improving on just the right needed abstractions. Related: http://number-none.com/blow/blog/programming/2014/09/26/carm... https://github.com/Droogans/unmaintainable-code |