" A good carpenter wants to build a solid house even if no one will ever see its frame. Ditto to an auto engineer at BMW, or a hardware engineer at Apple, or a

" A good carpenter wants to build a solid house even if no one will ever see its frame. Ditto to an auto engineer at BMW, or a hardware engineer at Apple, or a mechanical engineer at Boeing. Why do software engineers break this mold? " They don't, but a good carpenter is not going to try to figure out how to make every single wall perfectly 90 degrees, etc. He's going to take a level, see if the thing is in a center for a given stud, make that work, and then move on. They never perfect the end result. None of the walls in your house are likely perfectly square and plumb They also use imperfect building materials, and so they know that a year from now, even if it was square, it wouldn't be anymore. Carpenters, more than anyone, are true believers in "good enough". I'd argue most of your other examples are the same. That said, the problem she complains about is real. She is, in essence, a programmer from 30-40 years ago. When you had to share time on computers, and your software broke, you didn't just poke it repeatedly until it worked, because you couldn't. Instead, you sat on a mountain and meditated upon your code, until you understood it well enough to fix the problem and try again. In that sense, the thing that has really changed is not the cost, it's the speed at which you can throw shit at the wall. Development is so fast nowadays that programmers don't stop to think about the real underlying problem, they just want to make the compiler shut up or the program keep going. They just want to solve whatever their immediate problem is. The cost incentive was always there. People always wanted good software as fast as it could be built. It was the speed of being able to build it that made people concerned with quality. Now that they can essentially build it at light speed, nobody cares, because it's only how it seems to work that matters. IE doing things the wrong way to achieve the result people want is fine, even if it causes longer term problems. You can see this in pretty much any long-running (IE 15+ year) open source project.