The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
I’m a software coordinator who leads a Scrum team that unfortunately is generating a lot of bugs which annoys management. My manager says that the problem is a lack of individual accountability and that I should be forcing devs to repair their own bugs.
What may be some possible effects of this policy?
In my experience bugs are a consequence of (in no particular order):
As per the Lean methodology, ~94% of defects are caused by poor processes. Only 6% are caused by individuals.
Before punishing staff for perceived failures, have you actually done some sort of root cause analysis, using the 5 why's methodology or similar? Have you discussed the quality issues with the dev and QA teams?
The biggest drawback is that one has a very hard time seeing one's own errors.
I remember way back in the ancient days of COBOL, a fellow student couldn't understand why his code wasn't working. In COBOL, there is NEXT SENTENCE. He put "NEXT STATEMENT" instead.
He was looking at it for fifteen minutes and couldn't figure it out, until I pointed out the obvious error.
When we write our code, we are often blind to our own mistakes, and will often see what we intended over what we did.
It's an immense waste of time.
What would be the downsides of having a “you break it, you fix it” policy in the dev team with the goal of reducing bugs?
The downside is that you may spend a lot of time trying to chase down who introduced the bug, which in turn could lead to a "blame culture". There is a tactical way to address this situation right now and there is a longer term strategy at play.
The longer term strategy should be to reduce bugs period. Is your review process not rigorous enough? Is there not enough automated tests to cover the test scenarios? Etc. Put a plan together, execute and track your progress.
The short tactical way to address the current defects is to funnel them back into the team equally distributed across team members. Squash the mentality, if you see it, of being "above" fixing defects and only wanting to generate net new code. Addressing defects is a part of every software engineers' responsibility.
Let's back up a second.
I’m a software coordinator who leads a Scrum team
What's that? Because I can read the Scrum Guide to learn what a Scrum team is, and it tells me:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
[...]
Development Teams have the following characteristics:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
I'm not seeing anything in there about software coordinators creating rules about who fixes bugs; that's not part of Scrum. Scrum says the team organizes itself and chooses the best way to accomplish their work. How does the Scrum team address problems like these? Scroll down, and the guide tells me: the Sprint Retrospective
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.
In other words, improving quality is a team responsibility, and the team has regular sessions to plan how they'll try to do it.
Scrum is a process rather than an ironclad set of rules, and it makes sense to deviate from it based on the needs of the business and team. If you have a reason to follow a process that's different from Scrum, go for it, but at least identify the reason first. The scenario you've laid out here is directly addressed by the default Scrum process in the foundational text explaining the methodology, and you haven't explained why the team hasn't been trying it or why it hasn't worked.
So the question shouldn't be "what are the possible downsides of me imposing this rule on the team?" The question shouldn't be about imposing a rule at all. You have a quality problem, and you should have a self-organizing team that meets regularly to reflect on and improve their methodology: problem meet iterative problem-solving process. Assuming the team cares about the quality of their work—and if they don't, you have an entirely different type of problem—why not follow the Scrum process to address it?
I have no idea how to address this problem, but I suspect nobody should know better than the team themselves. If they think a "you break it, you fix it" policy will help, they can discuss that during a retrospective and agree to try it out for themselves. But there are probably any number of other things they'll want to explore and try as part of the retrospective process. They might:
Or dozens of other possibilities. I certainly don't know which ones are right for the team, but I do know that Scrum says the team is the right unit to examine the problem for themselves, choose some improvements to try for the next sprint, re-examine how it's going in their retrospective, and then do it all over again.
However, keep in mind that many efforts to improve quality will impact the pace of the work, especially when initiatives are new. The team may even decide they need to pause development entirely for a period to do something like improve automated testing coverage. That's where the last bit of the section on retrospectives comes in: the team changes its processes "if appropriate and not in conflict with product or organizational standards." Ultimately, management sets these standards. The team could almost surely improve quality dramatically by adopting the practices used to develop safety-critical software, but if your business is, say, running an e-commerce site and not developing an avionics suite, that decision will inevitably conflict with the organizational standard that changes need to happen more quickly. So it's going to be up to management to adjust its expectations in light of this new focus on quality. Remember that you can't beat the iron triangle: improved quality isn't free. If quality is suffering because the team is being pressured to do too much work too quickly, management's standards will have to change if they want higher quality.
Assigning blame in this manner is very likely to cause loss of morale and the emergence of extremely dysfunctional behaviours such as:
The rise of a blame culture will almost inevitably convince your best developers to find a new job.
Said that, I would question the assumption that the root cause of these bugs is lack of professionalism, because this is very rarely the case. In my opinion investing in your development process (CI/CD, QA, reviews, etc...) would be a better strategy than blaming individuals.
Your manager is misguided and taking you along on a misguided journey.
You break it-you fix it mentality places weight on assigning blame and dishing out punishment. What you’ll get will be “It’s not my code, it’s your darn requirements.”, or “You gave my method garbage data, garbage in-garbage out” or “The database is slow, my code is just fine”... you get the idea. Even if you get the “offender”, how do you ensure that he actually fixed the bug and not created more?
You will want to look into mature software development best practices for answers. Examples would be:
There’s more but the list above should get you started on a path to improving your software quality.
This isn't an issue of individual accountability lacking. This is an issue of the logistics framework allowing a large amount of bugs to leave your area. Or in short: What's Your Test Plan?
I've been dev-ringleader over three projects the last few years. The first had unit tests and a small number of integration tests built in to it. I could make a few clicks and verify everything was working within the code while making additions/changes. Because of this, very few bugs ever saw the light of day. The third had unit/integration testing built into the deployment process itself, and while we're not quite to the client testing phase, I'm pretty confident that there's not going to be a lot of bug appearances.
But the second? No unit tests. No integration tests. Just some manual testing of 'whatever we changed'. Care to guess how many bugs we were running into? I had to assign one of them off their regular tasks to develop an integration test suite retroactively in order to clamp down on relatively bad quality code we were putting out.
The mean answer is... this is your fault. You're the Software Coordinator, yet you're allowing your squad of devs to work in an environment with insufficient bug-catching. Where's the focus on unit tests? Integration tests? User Acceptance Testing? Etc.
Another big drawback I see is about code ownership.
In a scrum team, it's important that the entire team feels responsible for the entire product. This policy also means that if developer A caused a bug, developer B won't fix it, thus making sure he won't feel responsible for that code. This is likely to lead to an increased bus factor and friction within the team.
Instead, the entire code base should be the responsibility of the entire team. Therefore, if there are too many bugs, any solution should be implemented at the level of the team. Of course, if a limited number of team members does a poor job writing unit tests (for example) then that will need to be addressed. However, that's a discussion internal to the team. To the outside word, there should be a team, not a collection of developers (unless we're talking about a performance review, of course).
If a dev deploys something and it comes back in the same week, then the original dev is best placed to fix it. - I have found this works well.
However, if it has been more than a few months you can't really do this. The original dev will be focusing on another project, and breaking that focus isn't good. I worked for a company that tried 'you broke it, you fix it' and it led to a very toxic work environment with a terrible blame culture. It didn't reduce bugs, it just reduced productivity.
Those that avoid accountability now, will just find another way to do it. Literally had devs swear blind they had never worked on a project despite the repository history.
You need to find out why they aren't taking responsibility, and why work is coming back with bugs?
Find a way to give them ownership of their projects. I found that teams work well, having each job require at least 2 devs. They plan and work on the job together, becoming accountable to each other. If bugs happen it goes back to that team and they work on it together. Once they take ownership they wont want their software to have bugs in it.
I also found that devs took more ownership when we removed time logging, made budgets hidden and just gave them a deadline.
Your problem is that your developers produce code that is later found to be buggy, and that to a degree that your manager feels is too much.
There's always a possibility that you have a team manager who is just incompetent - in that case, that team member should not be the one fixing the bugs. That team member should be removed. But say that is excluded as a reason.
Here's what I've found what happens with agile development done wrong: You have tasks, you assign points, someone "performs" the task - but only to the point where they can say the task has been performed, not to the point where it is solid, maintainable, handling border cases and errors, and is bug free. You may be underestimating how many points should be assigned to a task, because you don't include the time needed to handle the task in a bug-free way.
That way you get developers who look highly efficient and produce buggy code. Worst case you have one or two developers who produce quality with no bugs, but take more time to perform a task, and are considered slow or lazy. When in reality they produce more useful work per hour worked.
So what you need to do is leave enough time to do the job properly in the first place. Because doing it properly in the first time is a lot, lot cheaper then doing a half-arsed job, and waiting for either QA or customers to find the bug, report it back, fix it, then QA has to review it again. Lots of time wasted.
(I have also seen software misbehaving for reasons that the developer absolutely couldn't know. In that case, the most experienced developer should fix it.)
The biggest issue I can see is that you probably won't reduce the bug count by any significance, but you will increase the pressure and stress on individual developers.
What you need to look at is why and how these bugs are occurring and getting through to production.
First up, communication. Do your developers talk to each other as they work on tasks? Do you talk about architecture and solutions in your scrum/sprint planning? Or does your team just agree to a bunch of stories at the start of the sprint and then work separately with just the morning standups?
Try to encourage pair programming - this will help with information flow, and should have a direct impact on big count. It doesn't need to be a full time thing - but you should try for at least 25-50% of the time. It might seem counterintuitive (two devs on one task!) but it can speed up development time with the information flow, and reduce bugs.
And document - make sure work is properly scoped in a way that covers potential side effects and impact. Also try to score stories and tasks such that they are as small as possible. Small changes have less side effects, and are easier to review (more on that later).
Next up is process. Automated testing and continuous integration is a must in modern software development, and has a pretty low bar for implementing these days.
Have your developers run a linter before they push code to catch silly mistakes like missing semi-colons. Get a static analysis tool to help identify issues with loops and conditionals and so on.
Agree to a coding style - having a standard style helps decrease bugs by ensuring things like all if blocks should be braced even if they're just a one liner (making it is harder to accidentally add a line of code that should also be in that conditional - a famous Apple bug), or switch statements must have a default. Have a tool that tests that style and automate it.
Implement automated testing. Try and do as small a unit as you can in these tests, but don't slavishly aim for 100% coverage. Sometimes a feature test is better than heavily mocking an MVC framework, for example. Testable code is also usually better structured and easier to change safely. Use tools that let your developers quickly and easily test what they're working on, without needing to run the full suite all the time.
Automate all your testing so that changes are tested by your developers before they push, and also on your repo after they push. Github, Bitbucket, and Gitlab all have CI pipelines to help with this.
Make sure your developers are rebasing their branches from master regularly (or at least before opening a pull/merge request) so that they can test their code against the latest master.
Have code reviews. Again, tested, documented, and tightly scoped work will make this easy. Larger changes should be reviewed as a pair between the reviewer and the original developer. I've heard of places that have a six-eyeballs rule - so, it a feature is developed as a pair, then a third person must review it. If a feature is solo developed, then it must be reviewed by two people.
A lot of this may seem like it would slow development down, but having good processes in place will reduce bugs, and will speed up development.
If the odd bug or two still gets through, look at what may have broken down in your process and try to change it. If it turns out that a particular developer is bucking the process, then hold them individually accountable. But until that point, bugs are the whole team's problem.
Assume you add a feature and rely on an existing function in the code, that was working quite fine until now.
Your code breaks, but it breaks because the function does not do what it should do. It worked for the existing code, but it does not handle edge cases, that are needed for your code.
Someone else wrote a unit test for it that does not test the edge case either.
Who is to blame?
Do you really want all these people to argue who is to blame?
And you may now be in the right place to rewrite this function. Why should you wait for some other person to fix this? You may even need to iterate this, as the fix may not fix everything and you need to ask them again to fix the remaining problems.
Stages of the software development life cyle as defined by the Agile Model:
Your problem appears to lie between stage 3 and 6. To reduce bugs in production you have to ensure the following:
A "you break it, you fix it" approach won't solve anything as it addresses the effect rather than the cause. Moreover a blame approach would just lower the morale of the team and jeopardize the project. The problem is always lack of a clearly structured and defined processes.
The main drawback would be developers actively trying to hide bugs (theirs and their colleagues'). The end result would be more obscure bugs, very well hidden.
This looks like a scenario straight out of the original freakonomics book. Go read it :-).
This wouldn't happen intentionally. It simply would happen that developers who code in a way where their bugs are harder to find get more time to code. Whereas good developers whose testing is readily available would be constantly stopped. Coding obscure bugs unintentionally ends up being incentivized.
The answer of @jeffrey is good, but I disagree in one thing: this is not the worst what can happen.
The worst thing what can happen is that developers will tip-toe around difficult code parts even more than before. They will artificially introduce boundaries just to protect them from the start from responsibility. The result will be that function complexity will be reduced beyond the reasonable point and it will result in separate functions and switch orgies which exactly cover the user stories (and yes, there are thing which are inherently bug prone). And nobody will do any non-trivial code cleanup or refactoring.
Bug are results of processes and team structures. No simple rule (an thisone would even be counterproductive) can change that.
If someone drives your car into a ditch, are they really the right person to trust to get it out?
Lets suppose for a minute that management is right, and for some reason the developers on this one team are much more apt to create bugs when they change code than the rest of the company's developers. Its not the nature of the tasks they work on (the most likely cause usually), its not some failing in management or requirements (the next most likely cause), its them.
Are those really the people you want fixing all the bugs? Eventually (in theory) you'd end up with your entire company's codebase dominated by code written by its most bug-prone developers. Sloppy code is orders of magnitude more difficult to maintain.
Perhaps instead it would be better to call in your better developers fix the problems, sort of like a technical commando squad. Then (and this part is very important), they write up what went wrong and instruct the weaker developers how to avoid this issue in the future. They need to learn better, or there's no way they can improve.
Fundamentally such proclamations remove a degree of freedom from your ostensibly agile team. When problems occur you are simply constraining the pool of people who can fix them for reasons other than optimality.
One argument from optimality would be that the person who wrote the code is best placed to fix it, which flexi notes but says only applies shortly after said code is written, while fresh in the memory (I agree).
You will probably find that it's often not expedient to enforce this rule - whenever the code needs fixing but the original author is unavailable. Consequently as well as all the described pitfalls around blame culture, extra pressure/stress etc, you are opening yourself to accusations of selective enforcement and potential gaming of the "I'm too busy" get-out.
One thing I have not seen mentioned here is that this strategy calcifies the code. Presumably the code of the different developers must interact. Say that one developer introduces a bug that is best fixed by refactoring another person's code.
What happens then? The other developer will oppose changing his code as then the bug becomes his problem. Over time, your codebase architecture becomes decided by age/precedence not engineering.
One point not made elsewhere is that non-trivial bugs are not simply attributable to one simple programming mistake. Typical example: you invoke a method (in "someone else's code", if you have such a concept) passing a zero-length array, and the code breaks because it wasn't expecting a zero-length array. Whose bug is it? Don't even waste time arguing about it, it's completely unproductive. Just decide between you whether to change the called code so it handles this input, or to change the calling code so it doesn't supply this input, and then decide who's going to make the change. Never even think of discussing whose fault it is.
