4 ms·
It's not technically a bug, but a "political compromise" by a self-professed "not a technical manager" who had aversion to including version numbers in API endp
by surfingdino 2y ago
It's not technically a bug, but a "political compromise" by a self-professed "not a technical manager" who had aversion to including version numbers in API endpoints. He asked us to come up with a way of enabling tests of a new feature in the API (new response payload schema). We submitted two proposals, one with v1/v2 endpoints returning payloads using old and new schema, or a URL param ?v=1 or ?v-2... He was not happy and asked one of the senior technical architects of the project to weight in and the guy said we should use the URL param. That was not good enough and we were told to go away and wait for a decision. Three months later we were told to implement a new cron job to deploy v2 into the integration test environment. Another cron job would then deploy v1 into that environment two hours after deploying v2. Yes, you read that right, v2 would be available for two hours per week, because a non-technical manager would not trust software devs to do the right thing for their colleagues testing their implementations of the API. I learned recently that almost a decade later those cron jobs are still there. If your tests are only working on day X of the week within a two-hour window, that's why. Sorry, cannot name names due to NDA.
- TrainedMonkey 2y ago> It's not technically a bug, It is absolutely an anti-feature. Most things in life function on some level of predictability. Computers are pretty high on predictability scale, do the least surprising thing and all that. I sincerely hope there is some kind of feedback mechanism for the "not a technical manager" to either learn or get less decision making authority.
- surfingdino 2y agoNo, the manager is still there having skilfully removed anyone who has any clue how to build, test, or deploy software from the organisation. And he does not accept points of view other than his own.
- tojaprice 2y agoWhat exactly is his aversion? Did he ever say? It seems like an inane hill for him to choose to die on.
- mapt 2y agoAin't dead yet.
- surfingdino 2y agoHe was never able to explain his reasons nor did he want to be told it made no sense. I saw similar behaviour in other orgs.
- burnerphone 2y agoSo, there was a single critical path, that for 2 hours per week was overwritten with the v2 code. This is pretty common. They wanted to test v2 in the regular environment, so they can see how it reacts to real user traffic. If it reacted well, they would replace v1 with v2 completely under the hood! See, they didn’t want v1 and v2, they wanted the existing endpoint updated while maintaining backwards compatibility!! Their system was too old or had poor test coverage, so in order to minimize risk of disruption to the service, they came up with the idea to try it out for 2 off-peak hours. Why do that vs better test coverage? They were confident enough, or the risk of breaking things for a little but was understood and justified, maybe they had some super old machines or configs they cannot accurately model and really wanted to get proper user traffic in. This is how many a/b tests happen too. Turn on feature for a segment, and then turn it back off. Or rolling deployments - have code run on 5% of servers then increase the percentage. Rollback if problem. This is that just except time based. Kinda hacky but everything in the story sounds reasonable to me
- surfingdino 2y agoIt was a new system, never went live in prod at the time. It was deployed to the integration environment where the API client implementations written by third parties would be tested against this new system. All that happened was a schema change. It made no sense to make it so complicated for the people the system was build for.
- mattnewton 2y agoThat’s insane