I have often felt the same way Brandon does in his post, The world runs on bad software, although I've come to believe that the frustration he is expressing has nothing to do with quality at all. It hinges on the fact that we should be building products people want, will use, and receive value from. Whether it’s good code or bad code, building a product nobody wants is not worth building.
Too often people fall into the trap that quality is king (admittedly I have done this in the past). I believe a cause for this is that people fail to realize that quality is merely a property of the code that exists, not the reason for its existence. If what the software does is valuable enough, people will use it whether it’s good, bad, or indifferent. So while quality is an important characteristic of software, it is trumped by the software’s ability to be something somebody wants.
Quality shouldn’t be thrown out entirely, though. It’s still important once we’ve identified what we should build. When I work on code I strive to do the best job I can, but that does not include an endless pursuit of perfection. It is a reasonable pursuit, in which I challenge myself each day to learn something new and to be able to write better software tomorrow. So I keep quality in mind, but I don't let it run things. If a piece of software is to be useful at all it will already have to meet some notion of quality, even if that level of quality is less than what we think it should be -- this is the craftsman’s dilemma, but that’s for another post.
In the meantime, let's focus on building products people want and then let's build them well.