The other thing you see is extraction of logic applied, particularly to business logic, prior to the actual logic being clear. So a developer will notice two v

The other thing you see is extraction of logic applied, particularly to business logic, prior to the actual logic being clear. So a developer will notice two very similar bits of code and maybe include some kind of parameter to a method or even worse, build some kind of abstraction (inheritance shudder) then as the project evolves it turns out there are actually very different business requirements for each case and you're stuck in a bit of a mess. As you say there's a cost to optimization, the wrong abstraction is far more painful than no abstraction. This quote from another blog post the other day is relevant I think: "Future thinking is future trashing When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future. But here is the thing: The problems from the future will never come and you'll end up either having to maintain a huge behemoth of code that will never be fully used or you'll end up rewriting the whole thing 'cause there is a shitton of unused stuff. Solve the problem you have right now. Then solve the next one. And the next one. At one point, you'll realize there is a pattern emerging from those solutions and then you'll find your "solve everything"." These are all just re-statements of KISS and YAGNI but it's definitely the most important principle.