We were just barely within the window to order a pair of new servers before the Itanium order book closed forever. Naturally, our old servers are too old for VSI to support, so HP was willing to sell us a license to give us time to migrate from the old legacy servers to the new legacy servers. It came with a warning that THIS IS THE LAST OPENVMS LICENSE YOU WILL EVER GET FROM HP AND YOUR CEO MUST SIGN THIS BEFORE WE GIVE IT TO YOU.
http://www.pvv.org/~roart/freevms.html https://github.com/rroart/freevms
After a while we noticed a pattern. Whoever 'blinked' first got a bunch of theatrics, including claiming a week for week slip every time (even if the problem was only one feature they barely used). Eventually half the teams would also claim a week slip. Anyone who missed that second deadline, the same process would repeat. Some teams who weren't 'the bottleneck' were still writing code week three.
Eventually we figured out that when we said a week, we meant 5-6 business days. When everyone else said a week, they meant 8-15 business days, and we suspected corner cutting even in those numbers. Over time we started 'helping out' people at the interfaces, slowly taking over ownership of more and more surface area. And yet these other teams still struggled to ship on time.
By the end I realized that this was the organizational principle the company was built on. Take a 2d plane of responsibilities, distribute people randomly on the plane, and where one fails to thrive, its neighbors grow to fill the space. You ship when most of the map is covered, and the gaps represent emergencies and/or lawsuits.
There is no special tooling for this since there can't be, you just have to roll up your sleeves and do the dirty work needed. It isn't hard, just a bit tedious if you want to do it properly. A junior developer can do it.
The trick is that the people asking for it almost always assume it's not going to be that much work, and won't be as slow.
So politically it's gonna be hard for you if you don't properly set those expectations on day 1.
The last one may mean you are solving np-complete problems to satisfy new bd.
Since you most of the time didn't code A, were not responsible for it, etc. and, at the same time, are expected to understand it thoroughly (you got the fg code after all), you're expected to do at least as good as A.
So you're B will be compared to A and will always be seen as inferior.
How treacherous.