Software falls over all the time, often in very avoidable ways that give the impression of simple laziness and/or incompetence.
E.g. Why do I need to use Safari to log into my bank account? I bank with a household name bank in the UK, but they've failed to make their web portal work with Chrome.
Why does iTunes let me set up a new iPad, but at the end of the process I get a choice between two buttons labelled "Sync" and "Done" - and I still have no idea what either is supposed to do, because sometimes I get a message about syncing to an old backup, or something, and the whole process is utterly counterintuitive.
Why can't operating systems handle paths with spaces or unicode with a standard convention for quoting that ensures consistency? It's 2016, not 1966, and this shouldn't even be a problem. But it is, for a lot of languages and operating systems.
And so on. IMO the author is right. We have a "dog ate my homework" industry made of quick superficial hacks bodged together, when we should have an industry built on solidly professional standards, conventions, and expectations.
Yes, the hacks ship. But if they don't work, how is that a success?
The attitude is built into the culture, and it shouldn't be. It should be impossible for anyone to become a professional dev without some lectures or lessons in domain analysis that forces them to confront a fundamental lesson - the problem is always harder and more complicated than you think it is.
A talent for cute math and logic problems is not the same thing as being able to dive into a novel domain, extract the essential elements, design a workable architecture to represent the elements, and then iterate towards a robust solution that can survive contact with users.
The median house will be used for decades, the median software is used for months (maybe days, or even minutes). This is really what my point is.
I reckon in most companies, software is written and maintained until the whole system it's a part of becomes obsolete. That typically takes years, sometimes decades if the system is really useful.
It's really risky to rewrite software, so it typically isn't done; it's similar with deletion of code. Most people shy away from it because they're making local changes and don't have enough global knowledge to be brave. So the code lives on.
Personally, in my professional career, nothing I've written has yet been retired or end of lifed, and I've been doing it for 15 years. Some things were experimental and never got released; some things were maintenance for a subsystem that got buried away; but no whole feature nor whole product has been discarded other than by gradual overwriting through maintenance.
This may be true for trivial web apps, but line-of-business software is often used for years, sometimes decades.
I find the beauty of code is not in adhering to someones concept of elegantly written code, that only the coders see, but in the fact that it's living, and that over time your solution can evolve to become better than its intended purpose. Something observed to be perfect usually has a past that is often overlooked.
I think the attitude of doing less things better is quite common among successful software developers. It's just hard these days to have a good experience while getting to a level where these values matter.
Even in those fields that people imagine involve a lot of perfection, like watercolors or fine Japanese carpentry, the perfection is not arrived at by agonizing over details and overworking the piece. The perfection comes from the muscle memory of someone who has done it many times. App development should be the same way.
This economy of effort is intrinsic to any craft and is part of being a good craftsperson. I used to have an attitude similar to the author, a mixture of derision and envy towards those who were able to ship. She needs to learn that if she does not abandon this counterproductive mental handicap, she will never be a good craftsperson, in software or anything else.