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?
This seems like a management/organizational issue, and so that means it needs to be handled by your manager, who would then figure out how to approach their counterparts on the other team. You would provide as detailed of info as you can to your manager, and leave it with them to best deal with that matter. If your manager needs concrete examples of how company time/effort is being wasted by the other team’s shenanigans, help them help you.
If you’re in engineering, your focus is to build stuff and make it work. And your manager’s focus is to maintain the prerequisites for you to do your job. This does necessarily mean that in the interim, while management works on a resolution, you may still be asked to fix some of their mess. And you should do so, in a professional manner, to the best degree that you can stomach. Obv, if management drags the issue out, then you’ll have to weigh your options, since it would demonstrate a management chain that isn’t doing their own job properly. And that’s no environment conducive to success on your part.
Yeah, I feel it might be a management issue too.
Unfortunately, everyone knows about the other team, but I feel they aren’t guided by their boss, Idk but I heard that they are lost on the project, but on that Idk how to help, but at least I expect them to test the code they produce, some of them test, but a lot of them don’t.
I’m going to try to help when asked, but it seems they need more senior devs (I’m only a junior dev) or some form of “training” for their project.
Can you put an ingest test on your systems?
Throw a flag when the JSON breaks etc and track those metrics.
If they are breaking production services, they sure wouldn’t last long on any of the teams I work with.
This 100% is a management issue, both their boss, and yours.
If resources are going from one team to another, and they have separate management, that damn well better be coordinated through your boss. At the very least C.C. at the start and end of the project.
I’m all for helping out another team, that’s what you do, but sounds more like constantly cleaning up their messes.
It happened inside their project, not in communication with our part of the whole. It happened communicating with the code we wrote for them, but we didn’t explain our code to them, so it might be a little bit of our fault, even if it was in the documentation and the tasks that were provided to us, the json was part of the documentation.
The resource I was talking about was you, not the JSON. Pulling your time away to fix it. That has to be coordinate a level above unless both teams have the same management.
If not you may your work impacted by it, as they say, cover your ass.
Oh, now I understand what you said and agree with it.
Also sounds like your software architecture may be too tightly coupled. If you are creating code that consumes input from the other team, the other team should only need to know what the expected inputs and outputs are. If they’re going in and making changes to your code then you guys need to merge teams or implement a review process (like pull requests in GitHub).