I’ve written a few times (here and here) about how every time you change something, every bug anywhere near that area now becomes your fault.
In my current job, I was in charge of a system called “Entitlements” that controlled who could do what and could access what parts of the system. Which means that dozens of new defects come to me with a note from the business analyst or equivalent person saying “looks like an Entitlement issue”. And I have to look at it and say “no, the reason they can’t access that part of the site isn’t because of Entitlements, it’s because NOBODY WROTE THAT PART OF THE SITE YET”.
Side note: we’re using “Agile Development”, which is a short form way of saying “we don’t know what the fuck we’re doing from day to day, and we’re not sure what has been done and what hasn’t until somebody complains that it’s not done”.
The good part is that because we’re Agile, that means when I discover that the problem is that nobody wrote that part of the site yet, I get to write it. So yay me.
That’s familiar. I once worked on the client-terminal software for a big system, and of course, every bug or missing feature got written up as a client-terminal issue. 90% of my time was spent proving that it was the central system that had the bug or didn’t support the desired functionality. The central system programmers were incredible assholes, and wouldn’t look into any issues until they had been officially re-assigned to them.
And, sometimes, they wouldn’t have time to fix a bug or implement a new piece of functionality, so we’d have to implement it in the terminal, even though it was clearly something that belonged in the server. We ended up with about half of the central system’s functionality in the terminal, as well as many hacks to fix-up missing/bad system functionality, and it really sucked when it came time to implement a new terminal.
Don’t tell me that your employer is using testdriven development, too, that is a *** of ***.