Here’s a situation that usually happens in some companies:
Announce interesting product X.
Promise a release date.
Release on the promised released date, ready or not.
Users discover and report defects.
Send patch after patch after patch after patch after patch.
My question is:
Ummm, what could be the factors that would lead them to tolerate these undesirable practices?
So, in the name of quality, what can be practically and realistically improved in those practicies?
I can think of time constraints, user feedback, sponsors pressuring the company, lack of money.
3
The main factor that goes into it is that the market will accept it. People are used to the fact that software is released with bugs, so will buy software even if they think it’s buggy
Then once that condition exists it’s hard to reverse. Think about it from the managerial perspective. We can either ship now, and start making revenue, or carry on sinking money into bug fixes that actually don’t affect our ability to sell the software; all the while giving our competitors an opportunity to release their buggy software that people will buy.
As discussed in the book geekonomics, this situation parallels that of the U.S. motor car industry in the 1950s-1960s. In that industry, it took every manufacturer changing their emphasis on safety, both in engineering and marketing, and the threat of government regulation to change how cars were designed and made. So far, that hasn’t occurred in software.
4
In my experience as a programmer, a project is never completed. We always have to update/add new features to it. Think about it, the mind of the software developer can never be the same as the end user/consumer. You can never tell what the consumer wants/like, so the best option is to allow them to test and then get feedback (very important) to help you upgrade it. It is a natural phenomenon; so that is why they have to do it.
1
Well, there are software development methodologies designed exactly with the aim to deal with this kind of release cycle. Agile programming and Extreme programming are just a couple of example.
As others noted, this (apparently irrational, apparently chaotic) way to develop software is actually well supported by many rational justifications. It is so common and deep-rooted that the software industry developed a few software development methodologies to deal with it.
As a consequence, it cannot actually be considered a scandal. It is just a matter of life and dealing with it is just a part of our profession. We can just study Agile Dev (or something like that) and learn how to use it effectively to deal with this chaos.
Agile and other similar methodologies actually work quite well. Most programmers think that these methodologies work even much better than many others (apparently better organized, more rational ones). As a matter of fact, Agile and similar methodologies are largely considered the only real way to tame software development in the real world.