So, I work in a medium sized team and earlier in this year, our team helped another that was behind in some tasks that all of us need to complete together.
After this, that team always asks for help from our team for untested things from their side and the worst part is whenever something breaks on their side, it breaks for a lot of people (like us) too, and they break a lot of stuff, simply not testing anything, no unit tests, no integration tests, nothing, they just throw broken shit out of the door.
This happens even to the things we made at their place, something’s up with our code? They changed it. It doesn’t seem to matter if it’s adding 2 lines to a sql query, they added an extra comma and didn’t test, they changed the batch processing? Now the process returns a broken json with different fields than the Enum expects. Yeah, they changed the value of the field that was ALREADY working for no reason and didn’t test it.
I’m pissed off, told my coworker that it’s their problem now, but the problems always come and the boss call us to help. This is very frustrating for us and for other teams too, even today another boss was talking about them breaking things in another system that we and they interact.
Their boss seemed to just want to give work for them, even with these problems coming back. The outsourced people work better than them, but you know, they are outsourced and the not so competent team is in house, so they can do nothing.
What can I do? Just saying no when the problems come? Talking to their boss?
Not sure how straightforward this is, but maybe instead of fixing things directly, point out to them what the fix needs to be. “Oh, you have an extra comma here. Try removing that and then see if it works.”
By forcing them to be the ones that work in their code base, and also forcing them to have to fix their own problems (even if you hand-hold them through it), then maybe they’ll start to show a little more care.
I showed an error to them, as their project is having a problem with the mock that I have built (for better managing and testing the dev environment) for the entire system and might cause very big problems when encountered in prod (very probable it will happen when the project will be used more, in some time in the near future), they didn’t fix it, it was encoutered 1 month ago.
At some point you have to let them fail. Remind them of it again, so that when they cause a major issue in prod you can point out that you communicated it to them multiple times. If this team keeps causing outages (and aren’t covered for by other teams) then, hopefully, management high enough will become aware of it and start to crackdown on them. I know you said elsewhere you don’t want them to lose their jobs but if they can’t do it, they shouldn’t have it. It’s not like you’re sabotaging them - you’re still helping them with advice and warnings. If despite that help they still can’t get by, then them getting terminated is the remaining best outcome.