Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

closed as too broad by gnat, MichaelT, Bart van Ingen Schenau, GlenH7, Kilian Foth Nov 25 '13 at 12:44

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

When the budget runs out, you release the product, ready or not. You use the revenue from sales to fund the debugging. – Hand-E-Food Dec 8 '12 at 9:08
@MuduM: would you feel better if the companies would not send patches early and let all discovered bugs stay in the product for months or years? For example, do you think Microsoft should not deliver monthly patches for their OS products? – Doc Brown Dec 8 '12 at 17:27
Is the actual question "why not delay the release?" – user16764 Dec 8 '12 at 17:49

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.

share|improve this answer
So overall i guess it all depends to the mindset of people – Jan Dec 8 '12 at 8:20
Yes, though don't forget that mindset is partially a result of vendor marketing. – user4051 Dec 8 '12 at 8:32
Users are used to buggy software. On the other side they are also used to get free updates that fix these bugs. A company that doesn't follow this second rule will close its business very quickly. – mouviciel Dec 8 '12 at 9:22
@mouviciel I think that's wishful thinking. Users are also used to paid upgrades that add new features and new bugs, including regressing previously fixed problems. – user4051 Dec 8 '12 at 10:38

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.

share|improve this answer
The question is not about adding new features, but solving bugs which would easily be discovered through testing & QA. – MainMa Dec 8 '12 at 9:51

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.