This is a re-worked answer to Scott Hanselman's great post 'Everything's broken and nobody's upset'. I replied it below the post, but I think it deserves a post here. Scott's post is about how we seemingly accept a long list of annoyances and issues with the software we use and how we apparently ignore the fact just how broken today's software seems to be. In my answer I tried to give an answer to why that is. This answer is below.
I think a lot of the problems with today's software are simply allowed to show up in public because the dev teams of these software products aren't given the time to fix them: Time to Market is critical, marketing already reserved a given launch date for the product, things are already in motion and only the bugs in the category 'it kills kittens and old ladies' are fixed at that point, the rest is 'moved to a later date'. But that later date never comes, because after the product is done, the team moves on to the newer version with new stuff, and fixing bugs is dreadful work, new stuff is exciting.
There's another thing about bugs which is also key in this issue: fixing them won't sell more licenses of vNext: people won't run to the store, yelling "OMG! They fixed bug 33422!!!1 I can't believe it!". They'll run to the store because new, shiny things have been added, like a completely new UI with ergonomic characteristics of which no-one really knows whether it's actually a step forward.
We, as software developers, all know software contains bugs, even though we did our best to fix them before RTM. But in the end, we have to admit that that label, 'RTM', is really just an arbitrary calendar event, not a landmark which says "0 bugs, It's ready!". This means that even though something went RTM, it doesn't mean it's bug free, it simply means: "It's good enough that it won't kill kittens nor old ladies".
A wise man, who unfortunately passed away way too soon, once said to me: "Your motivation and ability to fix issues and bugs is part of the quality you want to provide", which means: even though at first glance your software might look stunning out of the box, if that essential part of the quality of the software is missing, i.e. when a bug pops up it gets fixed, pronto, your software isn't of the quality you think it is. The insight given by this wise man opened my eyes all those years ago and I to this day still try to live up to it: stand for the quality you want to provide by giving customers the best support and software they could get.
If I look at today's software development landscape, I see a tremendous amount of people trying to write applications without the necessary skills and knowledge, in languages and platforms which have had a bad track-record for years, yet no-one seems to care, or at least too little. Last year I was in an open spaces session and some guy explained that they would place people who just started programming as 'trainee' at customers for 'free' and after a few months these trainees became 'junior' programmers and the client had to pay a fee per hour. I asked him what he thought of the term 'fraud', and he didn't understand what I meant. I tried to explain to him that if you think a person who has no training at all and you let him 'learn on the job' for a few months, is suddenly able to write any form of software, you're delusional. He didn't get what I wanted to say, and how it was a bad thing that someone with no skills was placed at a client as if the person knew what he was doing. Shockingly, some others in the room agreed with him.
But with the lack of highly trained professional developers growing and growing each day, more and more people who can tell the difference between a keyboard and a mouse are hired to do 'dev work', as the client doesn't know better and is already happy at least someone is there to do the work. I fear it only gets worse in the coming years. Frankly, I'm starting to get fed up with the bullshit pseudo-devs who seem to pop up more and more every day, who cry 'I'm just learning, don't be so rude!' when you tell them their work pretty much doesn't cut it, while at the same time they try to keep up the charade that they're highly skilled and experienced. You're either a trainee and therefore your work can lack in areas, or you're a professional and you have to take responsibility for the quality you say you'll provide.
Sadly this process of pseudo-devs which are seen as the true 'specialists', is in progress for some time now and will continue in the next decade I think. Let's hope they'll learn something about what 'quality' means with respect to software, that 'quality' is more than just the bits making up the software. But I'm not optimistic.