31

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?

you are viewing a single comment's thread
view the rest of the comments
[-] Weirdfish@lemmy.world 6 points 3 days ago

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.

[-] potatoguy@potato-guy.space 2 points 3 days ago

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.

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.

[-] Weirdfish@lemmy.world 3 points 3 days ago

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.

[-] potatoguy@potato-guy.space 2 points 3 days ago

Oh, now I understand what you said and agree with it.

[-] chickenf622@sh.itjust.works 2 points 3 days ago

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).

this post was submitted on 28 Jul 2025
31 points (100.0% liked)

Programming

21880 readers
268 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS