Good post. I think too that reducing code is key. Here is how I like to show it. Let's see what impact "size of code" has on "time it takes to add a feature".

Good post. I think too that reducing code is key. Here is how I like to show it. Let's see what impact "size of code" has on "time it takes to add a feature". Just consider a graph where the X axis is "size of code" and the Y axis is "time it takes to add a feature". Obviously, the function is increasing, and probably faster than linearly. Let's see what impact "size of code" has on "number of bugs". Same thing. Let's see what impact "size of code" has on "time it takes to find a bug". Same thing. Let's see what impact "size of code" has on "time it takes to resolve a bug". Same thing. Let's see what impact "size of code" has on "time it takes to refactor a piece of code". Same thing. Let's see what impact "size of code" has on "time it takes to a newcomer to be productive on that codebase". Same thing. And on and on and on. There is two canonical points on those functions. The first canonical point is when the codebase is too big for the value it brings. When you are here, you are in deep trouble. Basically, the cost of doing anything in that codebase is too high in comparison of the value it brings. A sign you are here is when you spend more time in meetings discussing what to do, than time coding. The second canonical point is when the codebase is notably small for the value it brings. When you are here, the project looks like magical. The programmers look like 10x programmers. Indeed, doing anything on the codebase costs surprisingly little in comparison of the value it brings. A sign you are here is when you are not asked for estimations.