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?
Discuss with your team management how to handle this.
- Guard and test against breakage of the interfacing (it’s an investment, but necessary without other solutions)
- Define requirements and actions you can stand by and reject for and and revert by
- Whether they want to tackle it on their management level (talking to the other teams or up etc); agree on timelines, requirements, milestones, and failure conditions regarding this
For this discussion collecting the impacts, in terms of labor cost, labor motivation, short and long term cost, repeated helping-out cost to your teams tasks, etc can underline significance.
No, don’t talk to their boss. They aren’t on your side. Talk to your boss. Any good boss will be an advocate for their team. I’ve often taken things up the ladder saying, “I know others feel the same way, but I’m not going to say names because I don’t want to out them if they aren’t comfortable saying it themselves.”
Anyway, being diplomatic is pretty important if you don’t want to be labeled a squeaky wheel.
That’s a job for THE MIDDLE MANAGER!! (imagine a crappy super hero)
No, seriously, do not step over your boss to talk to theirs. That’s like, the job your boss has, and they might get pissed at you, and, depending on pettiness level, make your life worse. Talk to your boss, explain how and why that’s a problem. Make it clear you expect them to solve it.
If and only if they say they can’t do anything, you may consider talking to your boss’ boss. But not the other team’s boss. Before doing that, I’d have hard financial evidence, like the other commenter suggested. Log your hours in their time buckets for at least a month, get others to join you in doing the same, get a report with total amount spent. Then you turn again to your boss and maybe include boss².
Talking to the boss seems a bad idea, yeah.
I’m thinking about doing a teaching session with the whole team (for the whole project), to explain things in the grand scheme of things of how they work, this might help with what each part of the code does. The project is huge, but the teams are medium sized and we are hiring a lot of people, so it might be good for all to know a little bit more.
If they’re not competent this will be a waste of time. I’m not saying it’s a bad idea, just have low expectations.
That team needs technical leadership on their end who can enforce standards and quality.
That’s leadership. Sounds like a plan.
If your boss wants you to fix their shit, that’s what you do. But I’d make sure my name went on their stories along with time spent. Ultimately someone will pay attention and notice they are a waste of payroll. Or search for another job.
Not our boss, their boss. We’re basically helping because of the spirit of the team.
They will not get fired and I don’t think that they getting fired would be good, I just want for them to learn about the system they work on and have more testing on their part. I want to work on my system, because I like it, only wanting to help when it’s needed, not when it’s not a good job on anothers team part.
If you are doing their job, why would they bother? What does your boss have to say about it? After all, his budget is paying for headcount that isn’t working on his objectives — which presumably results in a lower bonus payment. That’s who approves your time and that’s who decides what you work on. That other manager should be going through your manager with his requests at a minimum instead of to you.
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.
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.
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).
Is this a problem for you or merely annoying? I mean the difference between you being blamed for their poor results and you merely being inconvenienced by doing extra work.
You might need to train yourself to accept the situation as it is and hope for someone in authority to make things better. It’s not easy, but this might be a good chance for you to build that skill. 🤷
Can you talk openly with your manager about this situation? Would it be helpful to you to propose to your manager that you help that group? Maybe your manager would appreciate your attempt at leadership.
Good luck.
Just annoyed, I have some important work to do and then bam, a Teams call on the code we wrote and they broke. I would like to propose some help for them to understand better their system, yes.
Explain to your boss that it’s slowing down your work to have to take these calls. If your boss is fine with that, get in writing, ie. over email so you can’t be blamed for low productivity later. Now it’s not your problem.
If your boss isn’t fine with it impacting your work then get permission to decline these calls with “sorry I’m busy with my own work, please put something in my calendar.” Use your busy/available status in your calendar to manage when they can schedule these calls.
Good news, relatively speaking.
I’ve been where you are. Most important: don’t let yourself start to take responsibility for managerial decisions. If they want you to stand in the corner on your head and cluck like a chicken, it’s their money. 🤷 Don’t let that change how you see yourself as a programmer.
And roll your eyes in private.
Sounds like a long term issue that will not resolve itself. The only relevant advice anyone can give here is tips about job searching or sympathy.
You have my sympathy
Hahaha, thanks!
Your very welcome!!
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.
company wide policies.
building a proper ci/cd goes with that.
rules and delegations for each teammember.
some has to be the head and reviews.
time consuming probably. but professional in the long run.
The place I work has all that and even more, I think these kinds of errors that happen make upper management even more draconian with the rules (and we already have A LOT of rules).
how come that they can circumvent them?
merge is only allowed after passing the pipeline.
unittests have to be in place else merge is also cancelled.
they should simply dont get that far to make troubles for other parts of the codebase
how come that they can circumvent them?
Copilot writing all the unit tests and passing, while the unit tests don’t test anything or test the wrong thing. Passing the wrong thing to the services that consume their services, so it seems it works, but the service downstream just doesn’t work anymre.
for such things like shared documents/database entities also a shared test dataset should be available.
Then they cannot play around and modify those outputs anymore without noticing of others. (because their unittests would fail)
my assumption here is only an example. I dont know what youre dealing with.
While I understand the rant. And am on your side regarding those jerk moves. its a management issue. even when they do not act, its up to you to bring this to attention if this seriously conflicts with your work.
And in the long run its a win win for everyone.
edit: I am working myself in early development and despite being an engineer by background Im coding. So I know quite well how difficult it is to make it properly instead of quick and dirty.
