[Joeri]

You describe it as a zero-sum game, but it isn't.

Spending time writing documentation does not mean less time is spent coding, it means less time is spent coding that day, but then that is offset by time gained when someone later has to modify it and can finish sooner, thereby increasing the time available for coding other features.

This article struck a nerve with me because I've been at it 11 years, and feel much the same. The one lesson that has stuck with me most is the quality vs speed paradox: focusing on quality makes you go fast, focusing on speed makes you go slow. The reason is that if you cut corners you are continually wasting time fixing yesterday's cut corners, instead of implementing today's feature. You then feel pressure to rush through the new features to make up for lost time, causing more bugs to stack up, and... In extreme cases the project reaches a virtual standstill, spending all resources fixing past mistakes. Usually that's around the time it gets canceled, no lessons learned, freeing up everyone to do it over on the next project.

So, the issue is not one of budget, but of accounting. You have to account for the future cost of debts taken out on the codebase, and when you do you eventually conclude that the numbers tell you not to take out that debt. Convincing a manager of that however ... well, let me just say that it depends on the manager.

[gcb0]

your company gives you bonus per quarter. you have one quarter to impress with new features in production. you don't write code or tests, while team B does. you get 10 features, they get 4. q1 bonus is all your. your code is full of holes next quarter... but now that project is maintained by some junior Dev and you are crunching 10 features on the well documented project on team B because they clearly needed help shipping.

you get the bonuses every quarter.

[lordnacho]

>Spending time writing documentation does not mean less time is spent coding, it means less time is spent coding that day, but then that is offset by time gained when someone later has to modify it and can finish sooner, thereby increasing the time available for coding other features.

Exactly. But when managers don't see it that way, you have the utilization paradox: people are constantly working but constantly behind.

>So, the issue is not one of budget, but of accounting.

Yes and no. The two are intertwined. If accounting and estimation were correct, the budget would be correct on average. Instead, the budget is on average less that what it's supposed to be, because people do not account for everything.