43

I'm part of a back-end software development team, currently trying to fix bugs. We're seeing a problem wherein the front-end team will pass bugs to the back-end team by default for root cause analysis (RCA).

For example, the quality engineering (QE) team will file a bug stating that "doing X, then Y, then Z on the UI will throw an error when it shouldn't". The bug will be assigned to the front-end team. Sometimes, the default behavior it seems of the front-end team is to assign the bug to the back-end, with a comment akin to "We're getting an error from the back-end, therefore it is a back-end issue", and then assign the bug to my team without any inspection.

Over half the time we perform RCA and find that QE was right, and the bug is in fact not with the back-end, and assign it back to the front-end team. It's important to note that this RCA is on the front-end, not the back-end codebase, meaning that this process isn't out of the abilities of either team. Sometimes this happens multiple times, where the issue moves back and forth until it's finally taken by a team. This has been communicated to the team by our managers that we shouldn't be reassigning bugs like I've described, but the problem persists.

I'm having frustration in that I'm doing RCA on things that I don't get credit for or, in other words, I'm wasting time doing things that shouldn't be my job. At the end of our sprints, I'm behind on bug counts, and it looks like my performance is very poor.

How can I communicate effectively to the front-end team that I need to stop working on bugs that aren't in my area? Is there an amicable solution to both teams?

8
  • 28
    Does the front end team ever provide the "error from the back-end" that they are supposedly receiving?
    – sf02
    Sep 7 at 20:07
  • 16
    Can you close the bug as "Solved - issue not backend, opening new ticket for frontend." So that you get your merit? This might proliferate the toxicity though...
    – MonkeyZeus
    Sep 8 at 14:41
  • 10
    "I'm doing RCA on things that I don't get credit for" — sounds like the root cause analysis work isn't valued, which is weird, because finding the cause of a bug is sometimes 99% of the effort required to fix it. Sep 9 at 10:38
  • 1
    Is part of the problem here a lack of clarity over whether backend or frontend takes priority in driving solutions? i.e. if method getData() returns null in certain circumstances and that breaks frontend, should backend 'fix' this so that null can't arise, or should frontend add some error-handling code? Both may be reasonable approaches, but both teams need to be on the same page.
    – avid
    Sep 9 at 10:45
  • 3
    If your primary problem is not getting credit for the work, could you address that by creating a separate ticket for your investigation? You can then close that ticket when the investigation is done, and move the original ticket back if it turns out it is not a back-end issue, or otherwise solve the issue and then close it. Sep 9 at 13:46

14 Answers 14

174

There are multiple things to fix here:

  • From a technical perspective, if your frontend is getting an error reply and they cannot tell it's their fault, then the backend error reply is faulty. Fix your backend to reply with messages that can be understood and you won't need to explain it time and again.

  • From an organisation perspective, a bug you inspect, prove it's not your part and reassign should be a bug that counts towards the bug count. You successfully worked on it.

But most importantly:

  • From a product perspective, what the heck are you doing? Why are you two teams working against each other? Why are you assigning tickets instead of talking to your colleagues? What should happen is that the frontend dev calls you and says "hey, I have this nasty bug here, I tried but I cannot figure out why the backend is behaving this way, do you have time to solve this with me? I have set it all up, you can come over or we can share screens". And then you work on this together until the bug is fixed and the product is working. The product does not get one bit better by a bug count, or ticket reassignment or blaming one team over another. It doesn't make sense to have two teams. It's one product. There is no product without the frontend and there is no product without the backend. Your organizational structure is set up by corporate needs, not by product needs. And it shows.

What can you fix? I don't know. You could hunker down, hold the fort, make sure tickets get reassigned correctly, others take the blame and your bug count rises. This is how corporate works, you rake in money while stupid people above you wonder why their product is so crappy compared to the huge amount of money they pour into it. Or you could try to take the high road. Next time, investigate the bug, if it seems to be in the Frontend, don't just throw the ticket back, speak to someone, form a team with them and fix the bug together. Focus on getting the job done, not on corporate metrics. You might get surprised by how much more rewarding work is, when it's about getting things done, instead of deflecting tickets and blaming others. Maybe not. Maybe your corp is too far gone for you to make a difference. Then you have to decide whether they pay you enough to endure it.

2
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Sep 11 at 0:50
  • Why are you two teams working against each other? We aren't I don't think that there's anything that's done by either team that hampers total productivity.. Why are you assigning tickets instead of talking to your colleagues? Because they're asleep while i'm awake.
    – user53861
    Sep 17 at 14:36
46

I'm having frustration in that I'm doing RCA on things that I don't get credit for, or in other words, I'm wasting time doing things that shouldn't be my job.

Your incentive structure is screwed up.

Most likely, the front-end team is also doing this to get credit for inspection work that they haven't done.

If you want the behavior of the front-end team to change, the managers have to change the incentive structure and the way developers are judged.

35

I was in a similar situation at one point, with the added twist that the frontend was software and the backend was hardware (no access to each other's codebases). You mentioned:

the QE team will file a bug stating that "doing X, then Y, then Z on the UI will throw an error when it shouldn't".

and then these tickets would get forwarded to you. When I got tickets like those, I would kick them back as "needs more information". I don't have anything UI related on my backend, so the ticket from the QE team doesn't tell me much that's meaningful to me. Instead, we'd essentially require the frontend team to write up a separate child ticket - not reassign the original ticket - that says "when I send a such-and-such request to the backend that's formatted like this, the result is truncated".

This prevents the frontend team from lazily chucking issues over the wall and having you do the work. They have to debug the issue up to the interface between us. The end result was that 95% of the bugs they sent to us were actually backend issues. The process of debugging up to the interface would make it pretty clear which side the problem was on. It's hard to write up a description of what the backend is doing wrong when the problem's on the frontend. If they try anyway, such tickets are usually trivial to identify by (for example) showing that the same process works as expected when using a different frontend.

Using a second ticket between the frontend and backend teams also means you can close invalid tickets with extreme prejudice and it doesn't impact the QE team's original ticket at all. During a retrospective, you can show the number of tickets filed by the frontend team that were either invalid or didn't have enough information to be actionable, which should make the problem a lot more visible and obvious to management.

Essentially, stop crossing over the interface between the frontend and backend. You actually have the access and skill set to peek into each other's codebases (unlike my case), but just because you can doesn't mean you should. A big part of the reason for separating software into pieces like that is so that they can treat each other like black boxes with clearly defined interfaces. A backend bug should be ticketable without any reference whatsoever to a particular frontend, only to the backend's interface. If you have to lean across that boundary into another team's code to investigate your ticket, then whoever filed that ticket hasn't finished with their part yet.

I found it particularly helpful to have an alternate, simplified frontend to use for testing. My team rarely did testing using the official frontend (GUI). We put together a command-line utility from scratch that could exercise all the backend functions individually, and that contained none of the business logic that was in the frontend. That let us easily test our backend in isolation and verify its behavior against the spec. When a bug came in from the frontend team, we'd test the same sequence of functions manually using our utility. If we saw the same problem, the bug was most likely in the backend. When it worked fine for us, the problem was almost always in the frontend. We could easily identify tickets that weren't actually backend issues with a 5 minute test instead of spending 2 hours digging into it.

2
  • 2
    I really like this answer. Ideally the front end people would write an integration test for the back end that would demonstrate the problem. Sep 9 at 8:55
  • I like the idea, but it could deepen the mistrust between the two teams.
    – usr1234567
    Sep 9 at 21:01
22

This has been communicated to the team by our managers that we shouldn't be reassigning bugs like I've described, but the problem persists.

Why don't you address this with your manager? It seems that would be the correct channel.

At the end of our sprints, I'm behind on bug counts, and it looks like my performance is very poor.

Why don't you document this and present it in your sprints? "Here's why I'm behind..."

4
  • 3
    "Why don't you address this with your manager?" we did, that's why it was communicated by the managers, because we told them.
    – user53861
    Sep 7 at 20:22
  • 20
    Tell them again that the process isn't working. Give them the evidence that 90% (or whatever the number is) of the bugs assigned to your team are not the fault of your team. Sep 7 at 20:33
  • 1
    Yes, what Phillip said is right. But I would also add it may be working as desired from your managers perspective. So you need to prove it's not working. Sep 8 at 12:16
  • 2
    If they're kicking a ticket to back-end without justification, don't work on it, kick it back to them with justification of improper reassignment. Doesn't fix the issue, or problem, but maybe improves your teams' metrics. You can't help fix the systemic ticketing issues if you're fired for poor performance.
    – CGCampbell
    Sep 8 at 12:39
19

At the end of our sprints, I'm behind on bug counts, and it looks like my performance is very poor.

Sounds like you're solving the wrong problem. But first...

I think a lot of the other answers are assuming there is malice behind what the other team is doing, but there can be a number of factors on why bugs can be erroneously reassigned. They are not all good reasons, but they are reasons:

  • They think the ticket is more likely a problem in your team and they are triaging
  • It looks similar to other tickets that they have seen that have been caused by your team
  • They are overwhelmed with tickets and are looking to offload
  • They lack the ability to investigate
  • They don't want to do bug fixes

Ultimately, if there is some sort of systematic issue that you've already raised with your boss, you should ask your boss what they would like you to do when you get a ticket that doesn't look like it's been investigated before being reassigned.

Possible things your boss may ask you to do:

  • Assign the ticket back without touching anything
  • Assign the ticket back with a comment explaining why it should be reexamined
  • Work on the ticket anyway
  • Work on the ticket, but keep a record of time "wasted"
  • Raise it immediately with your boss
  • Raise it immediately with the boss of the other team
  • Raise it immediately with someone who is supervising support flow
  • Ignore the ticket
  • Close the ticket as not a bug
  • Close the ticket as not a bug, and create a new ticket to track the issue
  • Pick up the phone and speak with the person who assigned it to you
  • Seek a colleague's second opinion, and do one of the above if you both agree
  • Something else entirely

Any answer here that is prescribing what you should do in this circumstance is GUESSING what your boss would like you to do. Luckily you don't need to guess, you can just ask your boss.

While your boss has said that tickets shouldn't be assigned backwards and forwards without proper investigation, that does not give you licence do arbitrarily chose one of the above and do that. If someone is not following policy, it doesn't mean you shouldn't follow the policy either (as some other answers suggest).

Now, in terms of covering your arse, you also want to personally document instances where your own ability to work effectively has been compromised. And when you are discussing performance with your boss, this is what you should refer to. If you boss is happy with this wasted time, then there is no problem. Of course, if your boss is not happy with the wasted time, at least you've acted according to their directions.

5

I don't agree with the other answers. I have been in this situation and here's what I did to fix it.

As far as I'm concerned, as a developer, when a bug is assigned to me my job is to investigate it. Only if I verify it's not my responsibility to fix or for some reason I can't fix it do I reassign it to another developer/team. If I can't reproduce it or can't understand why it's a problem I will assign it back to whoever raised it.

You should ask your manager if they agree developers should investigate before reassigning. If they don't you are stuffed, but assuming they do ask them to make an announcement so that this is clear to everyone. If this keeps happening bring it up publicly in whatever venue is best in your workplace. A retrospective or status meeting for example. For instance - "I spent a lot of time this week investigating bugs that had been reassigned to me by FE which turned out to actually be FE problems. How is this happening? Why can't FE figure this out before reassigning to me? Are they not investigating properly?".

This might seem petty or blaming to some people but in a situation where people are throwing their work at you in the hope that some of it will stick, or at least it will buy them some time and the expense of yours, I think it is justified.

1
  • 2
    I would say if ANYONE can assign you bugs to look at, obviously there needs to be some sort of meaningful triage process that you do. My boss would get annoyed at me if I worked on a bug that got assigned to me only because it got assigned to me, even if it was crystal clear what the bug is, and I could fix it. I would also advise AGAINST questioning why others are not doing their jobs properly unless it is in a one-on-one meeting with your manager. Sep 8 at 12:21
3

Change the Bug Tracking System Rules

If users of a bug tracking system are misusing it then the privileges that they are using that is resulting in the misuse need to be revoked. In this case the ability to change the assignment of tickets to other teams.

Review Boards

I have worked on rather large programs that had many teams responsible for many parts. As such no developer was allowed to unilaterally reassign a ticket to another team. There was no hard system in place to prevent you from reassigning to another team, but if you did someone would be at your desk questioning what the heck you are doing. If someone wanted to assign a ticket to a different team they had two options:

  • Find and convince someone on the other team to take it.
  • Send the ticket to a review board that had a representative from each team present. There they would look at it and discuss which team was responsible for fixing it.
3

Your manager has already told you the answer.

You all are not to reassign bugs to the other teams.

When they assign you a bug, reply that you have been instructed not to interfere with their work and continue your day. You are creating the problem by cooperating with them instead of your manager.

You can let their messages go unanswered until it's a big enough 'heap' for your manager to micromanage and deal with all of them at once.

To clarify with an example, "QA has judged that the error is likely in your teams work and ManagerX has told us that you are not meant to be reassigning us bugs, and therefore we are prioritising the workload we were originally assigned. If you are able to locate the bug and find it is indeed an error on a specific output from the back end we will then take that as priority so that we don't delay your team."

17
  • 1
    "to micro" - "1. (gaming slang) to micromanage" Sep 8 at 10:38
  • 4
    I've worked in places where just ignoring a bug ticket to prove some sort of point would get you fired on the spot. And you can claim it's a managerial issue or whatever, but the bug history will show that a bug was assigned to you and sat unattended. Sep 8 at 12:25
  • 4
    -1: leaving bugs (especially high priority bugs) assigned to me where I cannot fix them is a terrible solution.
    – user53861
    Sep 8 at 13:54
  • 1
    @tuskiomi you are assigned work by your manager, not your colleagues as indicated by your instructions in the question. Sep 8 at 14:49
  • 3
    @tuskiomi They can write down that you are assigned work, but your manager is the one assigning you to either do that work or not, from your post it's seems that in these cases, it's to not do that work. Sep 8 at 15:23
1

This could be a great opportunity for you to be proactive - schedule some time each day with the lead (or some suitable representative) of the other team to triage the tickets together.

You'll get a better idea of each other's processes, probably reach faster conclusions, and critically, reduce the siloing. You'll now have dedicated time each day to concentrate on this task and your efforts are now measurable.

A bad manager will tell you that you've wasted time, tell you to stop and I'd take this as a sign that things at this company won't change.
A good manager will identify that you've done something worthwhile.
A great manager will help you develop the idea and iron out the process (and remember to give you credit!)

1

I struggle to see how so much time in your workday can be spent on bug fixing. You speak of front-end and back-end which seems to me to indicate a web stack of some sort, but how can bug fixing be such an issue that whole teams are skirting around the issue and trying to avoid taking responsibility for it?

If you are developing web apps then the investigation part of the design process should make the requirements of the app clear. Every developer should then have clarity on what is expected of the product.

What I suspect is happening is that a lot of junior devs are expected to work on technologies at a more advance level than what they are capable of. Who wants to employ a senior dev when you can just strongarm a bunch of newbs to work for a fraction of the price?

These people are instead of taking ownership of there work are passing the buck simply because they don't know how to fix the issue. It is often hard to admit you cannot solve a problem. Especially if you are fond of your employer and you think not being able to do something for them is letting them down.

I really don't see how whether an issue is front-end or back-end should stop anyone from fixing a problem. Yes, I intend to be employed as a front-end developer, but if the Angular app needs to interact with a MySQL database then it is my job to get it done.

I cannot throw my hands in exhaustion and stop working simply because I suddenly work with something that is technically not forward facing. There seems to be a disconnect in how these teams operate , they should be two parts of a cohesive unit. This us and them mentality is not conducive to good software development.

0

As suggested in a comment, perform due diligence, make your tests and if you find no bug in backend just close the ticket as "not a bug".

Frontend forwarded you the ticket and as a colleague you should expect they did it professionally and because of a reason: after some time maybe someone will notice a trend and decide to investigate.

Sounds petty? Because it is...

Risky? Maybe; only you can tell how much...

If the metric is "number of tickets closed", I think frontend will quickly notice the new approach in backend ticket management.

7
  • 1
    Or the OP will get fired for closing tickets regarding customer issues that aren't actually resolved. Because if I were manager and an employee was deliberately sabotaging customers, they'd be fired pretty quickly. Sep 8 at 17:25
  • @GregoryCurrie it looks like you completely missed the 'risky' notice in the answer. The risk assessement can be made by OP only; you and I can just make wild guesses and your is a reasonable one. Likely? Only OP can tell...
    – Paolo
    Sep 8 at 17:30
  • Moreover OP has issues with a lazy attitude from frontend that is not sanctioned. Why expect a different attitude from upper management dealing with a similar (petty) behaviour from OP?
    – Paolo
    Sep 8 at 17:35
  • 1
    Closing a ticket is way worse than reassigning. You close it, the next time you hear about it is when the customer asks why it isn't fixed yet. "Oh sorry, one of our developers closed it to send a message" isn't going to satisfy the customer. Sep 8 at 17:40
  • 1
    This seems a good solution to me if you also creates a new ticket for the frontend explaining what is causing the behavior (you can link both tickets with a causing/caused by relationship).
    – Raphaël
    Sep 8 at 20:12
0

How to tell front-end to stop passing bugs back by default ?

Grab all the relevant folks for a quick meeting and tell them:

I'm having frustration in that I'm doing RCA on things that I don't get credit for or, in other words, I'm wasting time doing things that shouldn't be my job. At the end of our sprints, I'm behind on bug counts, and it looks like my performance is very poor.

Ask them how they think this should be addresed. Have your manager present. Listen first.

0

Firstly, when you have one team working on the front end, and another team working on the back end, it is a good idea to design the systems such that front end bugs result in error messages and other messages that clearly implicate the front end, and ditto for back end. Problems in the front end should not be resulting in back end errors that make it sound like the back end is the problem, and then requires a lot of RCA to determine that it's not. If you guys had been all on one team, you could get away with this type of back and forth. But since you are separate teams with separate sprints, the passing of the buck is going to make things very inefficient, as you've discovered. So clearly you have a systems problem here.

Of course the problem is probably something that would take a lot of time and effort to solve (for example, how many errors would need to be refactored?) and you are looking for a quick magic incantation you can tell them that will make the problem go away. That incantation is:

Hey front-end guys - I've been noticing that we're getting a lot of bugs that at first seem like they're front-end bugs but then turn out to be back-end bugs, or vice versa. For example, last month the back-end team received X bugs of which Y turned out to be front-end bugs. I feel like it could make our lives a lot easier and save us much time if we reduced this back and forth. Can we have a meeting to agree on some better criteria for triaging bugs and filing as front-end or back-end? I have some ideas I can share if you like.

What's strange to me is that you state your motivation as not wanting to work on so many bugs. Isn't fixing bugs your job? If so, why are you complaining? Just keep fixing the bugs, mark the tickets done, and at the end of the quarter go tell your boss how you fixed so many bugs and should get a raise. Or if it's not your job, well, don't do it? Shouldn't you have a manager who tells you what tickets to work on, instead of having some other team dump tickets on you? Normally, tickets are supposed to go to your scrum master first, so that he can assign them to people at next sprint meeting.

1
  • 1
    AIUI it's not that OP doesn't want to work on bugs so much as OP isn't geting any credit for working on the bugs. FE sends OP a bug, OP spends time investigating that bug and discovers it's a problem for FE, who then fix the bug and get the credit for it and OP gets none. However, because OP is evaluated on how many specifically-BE bugs they fix, not how many bugs (of any type) they were involved in fixing, it looks like they haven't been working as hard as they should be. Sep 9 at 12:34
-2

Start assigning every bug to the front-end without looking at it. The problem with the front-end team (and your manager) will naturally resolve itself within a few days.

As long as they're rewarded for their actions by looking great in front of the managers, and you're the one who has to submit reports about poor performance, the front end team has no reason to stop their behavior; and they won't. Neither do the managers seem to care enough to do anything about it, if things continue as they are, you'll take the fall long before the front end team faces any blow-back.

5
  • 6
    "I can passive aggressive harder than you!" Sep 8 at 22:55
  • Yup. The other answers are on point when pointing out that the teams shouldn't be fighting and management should be on top of it and; yes, all of that is true. But it doesn't change the situation that the main poster is in and despite talking about it to management, the situation is worse, not better. Eventually, management will crack down and things will get sorted, but the poster might be driven out for poor performance before that point. So they need a plan to deal with things as they stand.
    – Rastilin
    Sep 9 at 5:16
  • @Rastilin Except that management has explicitly said not to do something, and that is exactly what you are telling the OP to do. Sep 9 at 6:12
  • Management has said that, but is not enforcing it at all to the detriment of OP. I've been in this situation before, a management ruling in your favor that they fail to enforce is irrelevant, they might as well have not said anything. This is how you end up being on call 24/7 because none of the other team members answer their phones during outages. Without enforcement, management may as well not exist, and there's no enforcement here. As long as OP is still required to fill out a report justifying themselves, it will just look like they're blaming the other team because they suck at their job
    – Rastilin
    Sep 9 at 6:55
  • 1
    The OP has suggested sometimes bugs gets assigned incorrectly. You're basically saying the OP should deliberately do a worse job that the other team, and deliberately going against the managers wishes. As the first comment implies, you're assuming malice of the other teams. But the only thing we know for sure that if the OP just starts reassigning everything to the frontend team, they are acting with malice. Management would see through this childish gamble. Sep 9 at 7:06

You must log in to answer this question.