Little confused on how to make product good

[AwNoodles]

So im about to make a product right, it says it should be .90 and 3.6 in the development thing, so i get it to that after about a year. I spend 3 months editing bugs, i dont know when its gonna stop because it was already at 50, so i just released it and it was mediocre. How do you know when to stop fixing bugs and developing, i miss the green progression bar ;(

[Traksimuss]

Bugs will not make product worse or better, it will impact how much people you need to support it when released. Mostly you will produce Good quality software, as outstanding is very hard to reach now. You can evaluate quality by using review, I always take Outsource.

[RoxiSinister]

Actually sometimes bugs do seem to effect quality, if it's bad enough to mention in the press reviews. But mostly quality seems to be determined by collective skills of your employees. Low skills bring down quality. Higher skills bring up quality. This goes for every skill used on the project, from designers, to programmers, to artists.

Skill levels also help determine the number of bugs which will be found. Testing on contracts, at medium skill levels, it looked to me to be in the ballpark of 50 bugs per unit of code. You can test this by looking at your contracts history and checking how many bugs the client found (and charged you for) and adding it to how many you know you removed in Beta.

For my own projects, with rather limited, inpromtu testing, it seemed to be a little higher. That was with one person (my founder) doing everything on a 2D Editor and then on an Audio Tool. All of the "relative" skills were at about 70% for my projects. They were both basic tools for the mid-80s, and I took out 350 bugs for the 2D Editor and 450 for the Audio tool. Both projects came out with Great quality. Support team found an additional 500 or so bugs between the two of them (I didn't really write any of this down).

[True]

Originally posted by 07CobaltGirl:

Actually sometimes bugs do seem to effect quality, if it's bad enough to mention in the press reviews. But mostly quality seems to be determined by collective skills of your employees. Low skills bring down quality. Higher skills bring up quality. This goes for every skill used on the project, from designers, to programmers, to artists.

Skill levels also help determine the number of bugs which will be found. Testing on contracts, at medium skill levels, it looked to me to be in the ballpark of 50 bugs per unit of code. You can test this by looking at your contracts history and checking how many bugs the client found (and charged you for) and adding it to how many you know you removed in Beta.

For my own projects, with rather limited, inpromtu testing, it seemed to be a little higher. That was with one person (my founder) doing everything on a 2D Editor and then on an Audio Tool. All of the "relative" skills were at about 70% for my projects. They were both basic tools for the mid-80s, and I took out 350 bugs for the 2D Editor and 450 for the Audio tool. Both projects came out with Great quality. Support team found an additional 500 or so bugs between the two of them (I didn't really write any of this down).

just wondering but how would i know if I fixed all the bugs?

[RoxiSinister]

It's unlikely you'll fix all the bugs on your own products until after it is released. Bugs will be found much more efficiently by the end users who number in the thousands, tens of thousands, and maybe millions than your Beta team will ever be. For contracts, it seems really consistent, however. Like I said in my previous post, I set a target number of bugs to find before I release it based on what I found in doing contracts. It doesn't always work out as well as I would like, but it's the only guideline I can actually visualize. Most of the time my support team can keep up with what is left over.

As an aside, you'll see the number of bugs begin to slow down with your team. At first it will rise rapidly, and after several months it will slow to a crawl. Because it is an unknown, that is why I use the guideline. Otherwise I might never release my products. I've had products with 150k users generate 200 bugs (simple tools like 2D Editor) and another one generate 1500 bugs (that one was an OS). Bugs won't kill your sales, as long as you're fixing them, and even if you're not it is really unclear just how much it impacts sales.

I know that isn't really all that helpful, but a lot of it is really a mystery, to me at least. I can only make observations and suppositions from them. I have not done any hardcore testing of the mechanic, and maybe someone else has, but this is how I do mine. I don't time my releases based on bugs found, but rather by other software companies releases, but that is another topic completely.

From my example above, early 2D Editors require ~10 units of code and Audio Tools require slilghtly more, maybe 14 units. Targets using the guideline mentioned earlier would suggest that the 2D Editor will have around 500 total bugs, while the Audio Tool will have around 700 bugs. I released at 350 and 450 respectively for a total of 800 bugs found during Beta. My support team found an additional 500 (approximately) bugs between them for a grand total of 1300 bugs. The guideline told me I would have around 1200 bugs total between them, so it's pretty accurate.

[True]

Originally posted by 07CobaltGirl:

It's unlikely you'll fix all the bugs on your own products until after it is released. Bugs will be found much more efficiently by the end users who number in the thousands, tens of thousands, and maybe millions than your Beta team will ever be. For contracts, it seems really consistent, however. Like I said in my previous post, I set a target number of bugs to find before I release it based on what I found in doing contracts. It doesn't always work out as well as I would like, but it's the only guideline I can actually visualize. Most of the time my support team can keep up with what is left over.

As an aside, you'll see the number of bugs begin to slow down with your team. At first it will rise rapidly, and after several months it will slow to a crawl. Because it is an unknown, that is why I use the guideline. Otherwise I might never release my products. I've had products with 150k users generate 200 bugs (simple tools like 2D Editor) and another one generate 1500 bugs (that one was an OS). Bugs won't kill your sales, as long as you're fixing them, and even if you're not it is really unclear just how much it impacts sales.

I know that isn't really all that helpful, but a lot of it is really a mystery, to me at least. I can only make observations and suppositions from them. I have not done any hardcore testing of the mechanic, and maybe someone else has, but this is how I do mine. I don't time my releases based on bugs found, but rather by other software companies releases, but that is another topic completely.

From my example above, early 2D Editors require ~10 units of code and Audio Tools require slilghtly more, maybe 14 units. Targets using the guideline mentioned earlier would suggest that the 2D Editor will have around 500 total bugs, while the Audio Tool will have around 700 bugs. I released at 350 and 450 respectively for a total of 800 bugs found during Beta. My support team found an additional 500 (approximately) bugs between them for a grand total of 1300 bugs. The guideline told me I would have around 1200 bugs total between them, so it's pretty accurate.

Intresting so it seems basically impossible or not worthwhile to go for all bugs fixed, but when I release a new product and have my support team finally fix all the bugs should I keep having support or quit support and just keep marketing up.

[AwNoodles]

Thank you for the tips, i played this game for a while about 4 months ago then took a break, alot of new stuff.

[Traksimuss]

Originally posted by True:

Basically impossible or not worthwhile to go for all bugs fixed, but when I release a new product and have my support team finally fix all the bugs should I keep having support or quit support and just keep marketing up.

It is not cost effective to catch all bugs (and I think not possible).
When catching bugs slows down considerably, I release the product.
And yes, users always find extra bugs.

[RoxiSinister]

I maintain suppport for a product until it has 0 active users, most of the time. If I release a sequel product, I might let it go once it gets to aaround 50 or even 100, but if your bug counts (not queues) aren't going up, then it's not going to have much impact on the support team anyway. I do this because dropping support while there are active users can negatively impact company reputations or folllowers (per the warning dialogue if you cancel support with active users).

I suppose you could fix all the bugs in Beta until it just completely stops, but it will probably take a very, very long time to happen. It's simply not cost effective to let it go on forever in Beta to achieve that goal. Generally speaking I keep a product in beta for 3-6 months depending on what kind of software it is, and when I have decided to release it based on the "Upcoming Releases" search for that type of product. Never release a product the same month as another competing product. If you can't beat them to market by a couple of months because your'e not ready, let it linger until 3 or 4 months after their release. I normally aim for May-June or November-December release dates. I also never announce a release date until I go into Beta, because changing your release date can be problematic.