> The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all. Have you ever heard of Premature Abstraction[0][

> The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all. Have you ever heard of Premature Abstraction[0][0a]? > Our codebase has a lot of big functions that do everything. The only time people try to break things up is to make it DRY. That's the whole point of DRY, though[1]. If you abstract with less than three instances of it, you will end up with abstractions that typically misfit the solution, requiring refactoring or outright disposal of the abstraction in the future (Or worse). Also, you waste time developing (what in all likelyhood are bad or leaky) abstractions when you could be devoting time to something more important. > Any time we need to change things, it breaks something else entirely unrelated. That's unrelated to abstraction. There, I said it. Leaky or badly fitting interfaces are not solved by abstracting more, they're solved by compartmentalizing more (There's a subtle difference here). This can be done with abstraction, but doesn't need to be. Typically refactoring the data structures, shuffling state around, or redesigning the interfaces to better fit the problem, is a better solution. [0]: http://wiki.c2.com/?PrematureAbstraction http://wiki.c2.com/?PrematureAbstraction [0a]: http://wiki.c2.com/?TooMuchAbstraction http://wiki.c2.com/?TooMuchAbstraction [1]: http://wiki.c2.com/?ThreeStrikesAndYouRefactor http://wiki.c2.com/?ThreeStrikesAndYouRefactor