Instead of talking of 'carrying' code -- Dijkstra frowned on that kind of metaphorical thinking (sensibly so) -- it might be clearer to rephrase and summarise this in more straightforward terms.
The problem here 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. That seems somewhat prudent, but it does not really attack the problem: we want to make code easier to change despite it being more complex.
Just limiting code size is not really a solution. Very broadly, functionality is proportional to code size (in general, and in particular where all else stays constant -- is that not reasonable?). So limiting code size is limiting functionality -- which is setting limits on what we do. We do not want that, we want to make things easier.
Also, this limiting really amounts to re-arranging the costs. It is transferring the costs of future change into costs of current activity. But instead of paying those moved costs by doing more work now, they are paid by having less functionality now. Is that not contradictory to one of the principles of agile (or at least XP)? You do not try to predict the future, you just do only what you need now.
The problem here 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. That seems somewhat prudent, but it does not really attack the problem: we want to make code easier to change despite it being more complex.
Just limiting code size is not really a solution. Very broadly, functionality is proportional to code size (in general, and in particular where all else stays constant -- is that not reasonable?). So limiting code size is limiting functionality -- which is setting limits on what we do. We do not want that, we want to make things easier.
Also, this limiting really amounts to re-arranging the costs. It is transferring the costs of future change into costs of current activity. But instead of paying those moved costs by doing more work now, they are paid by having less functionality now. Is that not contradictory to one of the principles of agile (or at least XP)? You do not try to predict the future, you just do only what you need now.