That's a good point. In a commercial kitchen one can declare "bankruptcy" by throwing out a single dish (or perhaps a set of dishes if one component was bad and

That's a good point. In a commercial kitchen one can declare "bankruptcy" by throwing out a single dish (or perhaps a set of dishes if one component was bad and the badness wasn't detected before use). But in software, declaring "bankruptcy" is the dreaded ground-up rewrite. It's like burning the whole restaurant down and starting over. I think another important difference is that software is much less predictable. Thanks to low/zero-cost replication, we spend much more time doing something novel than a commercial chef does. If a developer is doing the same thing over and over, that's a an opportunity to extract a service or a framework or a library. Whereas restaurants have much more predictable workloads, making it much safer to, say, chop 100 carrots than to write 100 classes in advance of need.