Comment by llll_lllllll_l
4 days ago
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
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.