3 ms·

> Shit breaks in ways you don't expect. It broke because it could not hit an unessential cloud service. This is absolutely something someone should have expec

> Shit breaks in ways you don't expect. It broke because it could not hit an unessential cloud service. This is absolutely something someone should have expected.

ChuckNorris89 5y ago
>This is absolutely something someone should have expected It's ok, we rushed the implementation to meet this sprint's goals, the fix is part of the next sprint. /s
- ziml77 5y ago
  I had the misfortune of working with a vendor that did work in sprints. I couldn't see it as anything other than an awful way to work that caused things to take longer than they needed to because priorities couldn't be shifted on the fly and anything other than break fixes couldn't be released mid-sprint. That fixed release cycle might make certain things easier, but it also causes a forced lag on all changes and encourages shipping code that isn't actually complete so you don't have to tell people to wait another 2 weeks for the change.
  - ed_elliott_asc 5y ago
    This pretty much sums up sprints, extra meetings at start and end, less flexibility (we don’t want to change the scope of the sprint) and generally worse for everyone. I wish some of Kanban was more widely accepted, especially things like making sure you have enough worked planned in the backlog to just keep taking tasks and working on them till completion.
    - robocat 5y ago
      https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 - “An epic treatise on scheduling, bug tracking, and triage” includes comments on software Kanban and has same well written hate on sprints.
- laumars 5y ago
  In fairness, this kind of mistake is the kind I’d expect a junior to make, and only the once. Putting time outs and other error handling around remote endpoints is prettier much the first lesson you’re taught when interfacing with remote end points. Yes mistakes happen and I’ve seen other companies ship products that have failed in similar ways, but I’ve always believed Microsoft is thought of as a FANNG and to see a school boy error in their flag ship product a couple of months before it ships really makes me question the standard of leadership running the team. Who’s QAing it? Why wasn’t those functions covered in unit tests? Who peer reviewed that code? And who’s running the development teams that allow all this guardrails to fail? It’s not just one engineer who had to fuck up to cause that bug.
deleted 5y ago
[deleted]

> Shit breaks in ways you don't expect. It broke because it could not hit an unessential cloud service. This is absolutely something someone should have expected.

ChuckNorris89 5y ago

>This is absolutely something someone should have expected It's ok, we rushed the implementation to meet this sprint's goals, the fix is part of the next sprint. /s

ziml77 5y ago
I had the misfortune of working with a vendor that did work in sprints. I couldn't see it as anything other than an awful way to work that caused things to take longer than they needed to because priorities couldn't be shifted on the fly and anything other than break fixes couldn't be released mid-sprint. That fixed release cycle might make certain things easier, but it also causes a forced lag on all changes and encourages shipping code that isn't actually complete so you don't have to tell people to wait another 2 weeks for the change.
- ed_elliott_asc 5y ago
  This pretty much sums up sprints, extra meetings at start and end, less flexibility (we don’t want to change the scope of the sprint) and generally worse for everyone. I wish some of Kanban was more widely accepted, especially things like making sure you have enough worked planned in the backlog to just keep taking tasks and working on them till completion.
  - robocat 5y ago
    https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 - “An epic treatise on scheduling, bug tracking, and triage” includes comments on software Kanban and has same well written hate on sprints.
laumars 5y ago
In fairness, this kind of mistake is the kind I’d expect a junior to make, and only the once. Putting time outs and other error handling around remote endpoints is prettier much the first lesson you’re taught when interfacing with remote end points. Yes mistakes happen and I’ve seen other companies ship products that have failed in similar ways, but I’ve always believed Microsoft is thought of as a FANNG and to see a school boy error in their flag ship product a couple of months before it ships really makes me question the standard of leadership running the team. Who’s QAing it? Why wasn’t those functions covered in unit tests? Who peer reviewed that code? And who’s running the development teams that allow all this guardrails to fail? It’s not just one engineer who had to fuck up to cause that bug.

deleted 5y ago

[deleted]