4 ms·
The worst? Data Loss, or corruption, which is worse than "not working". Likewise, more likely it could just not work well, be buggy and require several updates
by lt 17y ago
The worst? Data Loss, or corruption, which is worse than "not working".
Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.
Again, not justifing it taking ages, just saying there's never an excuse to skip QA.
- bumblebird 17y agoThere wasn't any data. It did X with the external network. The worst case was that it maxes out the connection and burns through bandwidth. But that's something that can be monitored. The customer would have rather had something working with the network, than something broken with the network. In that particular circumstance, there's always an excuse to skip QA. IMHO.
- random42 17y agothere's always an excuse to skip QA. IMHO. No, there isn't!
- roundsquare 17y agoThe worst? Data Loss, or corruption, which is worse than "not working". Thats a good point (even though in this case it turns out not to be true). Seems like the right answer is to back out the change.