In my experience of writing enterprise software, the main offender is N+1 query problem at an API boundary. I.e. when a module/package exposes only a method to

In my experience of writing enterprise software, the main offender is N+1 query problem at an API boundary. I.e. when a module/package exposes only a method to process items one-by-one. In case you suddenly want to process 1000 items instead of 5, you'll end up having 1000 separate DB calls, HTTP calls etc. Same applies for gamedev where the author is coming from: a naive renderer could switch shaders individually for every object when you want to sort by shader and switch only a few times. When peformance suffers, you have to change 2+ modules (the client and the server) to support batch operations and a lot of programmers don't have time to do it or simply can't do it because they use a third-party module/service they can't change. Inside a module you can default to clean code or switch to an optimized version if need arises. In a small, well encapsulated/defined module you can write very simple code without overengineered abstractions because it covers a simple model which doesn't need too much abstraction. So my take is write small modules, design abstractions at the API boundary, and always expose batch operations.