Yes, exactly - everything you have said here is excellent. There are many points here, so I will try to answer each of them in turn for structure's sake.
As you pointed out, chefs and architects are a bit of a limited example because the project is comparatively small - a recipe, a house, each has comparatively few layers, so to speak. Software on the other hand tends to have an awful lot of layers, and as you said software is much easier to launch into and get wrong (given the number of layers, it's practically impossible to see what it should be in the end from the start).
I attach massive importance to the concept of allocating a percentage of time to debt, personally speaking. In the last company I worked in, ALL teams were instructed to have 100% billability for about a year or two (i.e. zero maintenance whatsoever unless the customer asked for it), and you can imagine how that went. Of course, my anecdote is a very small sample size - but at least in my opinion, it can't be stressed enough that the concept of time% allocated to technical debt should be a general rule as opposed to an occasional convenience, because without it commercial reality in my experience tends to mean "either you do it all the time or it will never be done, because some customer request will always be seen as more important and it will never begin". I've rarely seen a company that understood the concept of long-term thinking in this way, largely since short-term considerations tend to be seen as more 'urgent' due to their short-term nature, and due to yearly financial reporting. You're right to say that Agile helps here, but I would still argue that's less 'Agile' and more 'small project granularity' (small waterfall-like things, irrespective of methodology), but I think there we are just debating terms and are on the same page on the practical stuff.
One thing I have realised from your critique is that I have failed to properly account for, and talk about, the fact that many developers did indeed go through horrible times with how Waterfall was often implemented in the past - and the relevance that has in terms of Agile's current prominence and the views of many developers on it. Given Agile's near-holy status in many quarters, I did not think it was that important to explaining the issues at hand, but after analysing what you have said I think it is fair to say I was entirely wrong to think that. I should have communicated that better by talking much more about the points you have mentioned about the problems of Waterfall in previous times, precisely why Agile came about from it, and so forth.
I will make extensive revisions and additions to the article to account for this - and to give some defences of what Agile was meant to be, a sort of "history of the transition from waterfall to agile", something which really needs to be there in order to explain these points, alongside your point of applying my analysis to those smaller fragments. Thank you very much for taking the time to bring this shortcoming to my attention - I will make sure to thank you in the article when it is revised. (That is not intended to mean "end of conversation" or something, I just thought it was important to say it right now. Feel free to continue.)
