4 ms·
Agreed. The last company I worked at we had some similar idiocy. We had a backend process that connected out to a network and did some things. However, the net
by bumblebird 17y ago
Agreed. The last company I worked at we had some similar idiocy.
We had a backend process that connected out to a network and did some things. However, the network it connected to changed their protocol, so our backend process was broken - didn't do anything - completely non functional.
We created a fix, but had to wait for it to go through QA for ages. What's the worst that could happen? It doesn't do anything like the current version? It wasn't even a massive update. Maddening.
- lt 17y agoThe 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.