3 ms·

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you co

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you could switch to a competitor but that's not that simple either. Switching jobs? I mea yea you could but again that's not exactly an option for a lot of people. Particularly in the short term. Mean while your app is stuck on a loading screen with an infinite spinner and bad reviews are flowing into the app store.

Aqueous 8y ago
In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity. Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.
- int_19h 8y ago
  To make an analogy pivoting on contracts: modern programming is often not a "rule of law" environment. If you try to pretend that it is when it's not, you're just going to get a lot of pain. And you can't fix everything by yourself. At some point, the most efficient way to push back against bad code is by validating the contract at the boundary. Then, when that breaks, you have a lot more leverage to go around and demand fixing things. Or, better yet, use systems that don't allow contracts to be so easily broken. Static typing is an example of that.
mpolichette 8y ago
Getting the problem fixed is about culture as much as anything else. If there is some legacy reason something cannot be fixed and has to keep returning bad data, then yes, there is 100% a reason to have two endpoints that do the same thing... usually prefixed with /v2/ or something

3 ms·

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you co

by mdgrech23 8y ago

Aqueous 8y ago
In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity. Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.
- int_19h 8y ago
  To make an analogy pivoting on contracts: modern programming is often not a "rule of law" environment. If you try to pretend that it is when it's not, you're just going to get a lot of pain. And you can't fix everything by yourself. At some point, the most efficient way to push back against bad code is by validating the contract at the boundary. Then, when that breaks, you have a lot more leverage to go around and demand fixing things. Or, better yet, use systems that don't allow contracts to be so easily broken. Static typing is an example of that.
mpolichette 8y ago
Getting the problem fixed is about culture as much as anything else. If there is some legacy reason something cannot be fixed and has to keep returning bad data, then yes, there is 100% a reason to have two endpoints that do the same thing... usually prefixed with /v2/ or something