The problem is that larger code is more complex, and more complex is harder to work on. The suggestion is that we impose limits on the amount of code. Limiting? – yes, the article says code will be deleted and the client will have to choose what to save – so the rate of deletion is at least as large as the rate of addition. This deleting and adding is effectively the same as limiting.
The basic idea of limiting appears prudent: limiting code is limiting complexity, which limits the difficulty of work.
Broadly, functionality is proportional to code size – in general, and in particular where all else stays constant. So limiting code size is limiting functionality – which limits what we produce, what the client gets.
But we do not want to do less, we want to make things easier to do. So the proposed solution does not really attack the real underlying problem: we want to make code easier to change despite it being more complex.
It is not a criticism that the solution suggested does not do more – that is really more a project for computer-science/software-science, not software-engineering practice. But it is worth noting.
The proposed limiting really amounts to re-arranging the costs. It is transferring the costs of future change into costs of current activity – future work is made easier, by making current work harder. But instead of paying those moved costs by doing more work now, they are paid by having less functionality now.
This is contradictory to one of the principles of agile: you do not try to predict the future, you just do only what you need now. Agile is feedback-driven not forecast-driven.
And if the proposal is taken to really mean deleting and rewriting rather than just limiting, that just strengthens the contradiction since it not only limits functionality it adds the extra work of rewriting too.
What makes predictive work bad is not really that it is for the future but that it is for the unknown. So if some solid information and knowledge can be got, ‘predictive’ work could perhaps become reasonable enough to do.
The way to do that is probably to conduct general experiments somehow and/or gather measures (perhaps like this earlier note on ‘Software Registries’). Instead of having developers rewriting on the job, make it a proper investigation – and move the learning out of the client project.
There are two layers of learning/information here. The agile process is itself a learning process: it discovers (and makes) what the client wants by direct interaction between them and the construction. But proposing behaviour now, like limiting (or deleting/rewriting), to help what might be wanted in the future is not direct. So any knowledge backing it must come from elsewhere – separate proper experiment/measurement. This recognises there is specific knowledge to be got on the job, and more general knowledge that can be (and ought to be) got from more general research.
Ultimately, agile is not about doing less, it is about doing only what you are clear about.