"Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design against unintended consequences."
Wikipedia Software Reliability
The six paragraphs in this explanation on Software Reliability are bang on in my experience. In fact, the statement above best describes the difference between project success and failure. The more disciplined the software engineering process the better quality the output, in all measurable aspects, is my conclusion after 18 years as a software professional. Btw, disciplined != bureaucratic || inefficient.
I wonder if software reliability engineering had been applied to the following web sites, it would have been less likely for me to see these messages:
The irony here is that these two messagess occurred on two seperate dates, not just 20 minutes apart 
An Error Has Occured? Pics or it didn't happen! Oh... well how about directing me to another download site that is known to be working? I can't imagine what's in the "On-line Self Help."
No way man! 
Aeroplan, a fairly large transactional site, was down for two days. I wonder if software reliability was on anyone’s minds when the site was designed…
You may have noticed that some of the screen shots show maintenance messages, not error messages (and other reliability messages). I find it hard to believe that there is (still) the practice of scheduling "planned outages" for web application/site maintenance on the main public domain web site. First business rule in the world wild web, you are always open for business.
Sure, some of these sites have staggering amounts of traffic and processing. However, it is 2009, where computer hardware has never been cheaper and the most powerful at the same time. Content Management Systems and Ecommerce systems, have never been more plentiful, more mature, and the most featured for the least amount of dollars.
That’s one of the points behind having a disciplined "software engineering process." One of the most important activities, in my experience, is designing for software reliability. No, I don’t mean life and death reliability, but given the budget constraints, what is the best or most acceptable "business risk" the web application/site is able to mitigate from a reliability point of view.
What do I mean by business risk in this context? Given that Aeroplan was not able to transact business for two days, let alone how it looked to "customers", I would be surprised if the executives signed off on that their main public web site could be down for a two day period. And no, I don’t mean "high availability" or five nines uptime, albeit related, I mean software reliability. Even if you paid for five nines up time, it is very likely your software will error out (or you planned a maintenance window!) well before you hit that uptime number. I would say that this is predetermined by how your software was designed and engineered.
I wonder when the "tipping point" will occur where the general public will stop accepting software that is the analog equivalent of missing a wheel on a car. Sure you can drive it, but not very well. That’s the ultimate problem with software, it is completely invisible to the majority of people, but if they saw it, and it looked like a car, then they would see that missing wheel, hear the engine misfiring, and see/smell the smoke bellowing out where canola oil was used instead of engine oil. The car is clearly a lemon and would not sell. Even if it did sell, there is a lemon law.
Yet software contunues to be built, and software products exist today, that are the equivalent of the lemon of a car, but there is no lemon law or even a guarantee of any sort for software. There is a reason for that. Some would say that software is too complex or at least no-one, other than NASA can afford the level of software reliability engineering that we comparatively see in our cars today. Do you think that is true?
Based on my experience, I don’t think so. In fact, over the mid term and long run of a software lifecycle, spending the engineering time to design the software correctly (or as best as possible given budget constraints) easily costs (considerably) less than just trying to bang the software out using the latest du jour software process methodology and then fixing the heck out of it for years to come. At least my own anecdotal experience supports that position.
These software quality issues were screen snapped over a couple week time frame while I was browsing the net. What does it mean? I feel it means a couple of things. One is that I am one person, the smallest possible sample size, yet look at the poor quality software I encountered during a short time frame. I can't imagine what the impact is on millions of users sampling (hundreds of ?) thousands of web applications/sites daily. The other is there seems to be far and few between companies that actually practice designing and engineering software in a disciplined manner...
Updated Next Day - Ha!
