0

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.

Jan
  • 153
  • 1
    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 08 '12 at 09: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 08 '12 at 17:27
  • Is the actual question "why not delay the release?" – user16764 Dec 08 '12 at 17:49

3 Answers3

5

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.

  • So overall i guess it all depends to the mindset of people – Jan Dec 08 '12 at 08:20
  • Yes, though don't forget that mindset is partially a result of vendor marketing. –  Dec 08 '12 at 08:32
  • 2
    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 08 '12 at 09: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. –  Dec 08 '12 at 10:38
3

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.

Jevison7x
  • 240
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.

AlexBottoni
  • 1,531
  • 10
  • 10