[ilaksh]

This comment and many of the replies are ridiculous. Bugs are part of the process and so is QA. Having only a handful over a few years probably means you spent too much time trying to make it perfect. You will see fewer problems the more time you have to work on a feature or test it, but in my opinion if you consistently get to zero then that is inefficient because it delays the feedback from the user. Or it means you have a really well funded organization that can afford a lot of development time on each item but is probably wasting money.

You have the "luxury" of a QA team, unlike many developers. Take advantage of that. Don't feel bad just because you see a bug once a year (which I don't believe is accurate reporting on your part).

[llll_lllllll_l]

Yah, making it clear, I def get more than a couple of bugs yearly hehe. You sound right for me, and I heard stuff like that from companies here and there. Stuff like "delivery it first, make it better later", like focusing on putting it together on front of our users besides of over engineering the right thing. This is cool, till dozens of bugs appears

[adamhp]

It's the right mindset. Because code isn't the end, it's a means to an end. The end is "value". To your users. The quicker you give that to them, the better. Bugs here and there are absolutely part of the process. You are making an assumption that the least amount of bugs is "best" for your company.

It's important to consider the bigger picture here. Consider a scenario where you spend twice the amount of time delivering features, getting things perfect. Let's assume for the sake of it, that our users will "like" half the features we ship, and we'll throw out the rest. In this scenario, it's better to reduce quality to ship faster, because half of your features are going to be "thrown out" anyway.

This happens in the real world, albeit to a less extreme extent. But the point remains. That's why we have product teams that attempt to reduce the likelihood of a feature being tossed out and time being wasted. That's why we have QA teams to ensure development bugs are caught and we deliver both value and have robust systems in place.

As long as these aren't catastrophic, affects-all-users, brings-down-the-servers type of bugs, you're probably writing the optimal amount of bugs to balance the trade-off in value delivery.