Is "You break it, you buy it" the best policy?

Question

There is a subtle reason why it might not be good: Sometimes, the blame for breaking something really should be placed on the individual who wrote fragile code without automated tests, not the one who broke their code by making a should-be-unrelated change somewhere else.

One imaginable example is when someone programs against an interface in a way that assumes behavior specific to the implementation du jour, but not guaranteed by existing contracts. Then someone else makes a change to the implementation that fits in the contract, but breaks the depended-on code. No tests fail because no tests are written for the depended-on code. Who's really to blame?

The purpose of this isn't to blame people, but to understand responsibilities, and if "You break it, you buy it" is really such a good policy.

EDIT: I really worded this poorly. I meant it to be about how to write correct software with respect to dependencies, including hidden dependencies. I meant this to be a question of what a programmer's responsibility is to avoid bugs, not what to do when a surprise bug is found. BUT, since so many answers have been given already, I'll let the question stand as-is and indicate an answer accordingly.

Answer 1

Fixing it is the purpose not laying the blame. Suppose the orginal author of the fragile code has moved on, who would own the problem? Suppose he or she is simply assigned to another project? The person who ran into the problem needs to be the one who owns it until it is fixed, he or she is the person currently there and currently assigned to the task of making changes to the application.

Now if you know the code was created with a problem that should be avoided in the future and the orginal developer is still there, it would be a good thing to let him or her know about the issue and why it caused a problem, but ultimately the person who ran into the problem is the one who will need to fix it to get his new code to work.

Answer 2

I would say that assigning ownership to the disaster prone may not always be the most productive strategy. It is likely its own reward.

Answer 3

In an environment where people have to work together, cooperation should be of greater importance than placing blame. If someone`s module is fragile and if his/her peers agree that something should be done about it, a good team-player would fix the problem; that is, he would write unit tests .etc

In any case, a programmer's own code is ultimately their responsibility, and if they can't handle the responsibility of making their code cooperate with that of others, then they rightfully must take the blame. But not before giving them a chance or two to clean up their act.

Answer 4

I think you have nothing to gain and everything to lose by promoting an atmosphere of blaming and finger pointing. When something is broken, you should assign it to the best person to fix the problem, whether that is the last person to touch that area because he or she knows the area, or to the person who wrote it first so knows the design philosophy best, or even just the person without anything more pressing to do.

Answer 5

The last person to touch it should be at fault, Refactoring is a large part of software development, if somebody touched the code and did not properly document, write and test the code than that is on them. As part of the estimate, the time to properly put the code in better shape than it was found should be included.

That being said, if something does not work, the whole team should take the fall.

Answer 6

Typically I hand out defect fixes to those who are best capable of fixing the problem. If they are unavailable I give it to someone else. Who "broke" it is irrelevant.

Answer 7

"You break it, you buy it" makes sense in terms of breaking builds, not more serious problems.

If you put the build into a state where it can't compile, or run basic tests, you are blocking other people's work. If you can't see a quick and simple fix (because you introduced a quick and simple bug) then just roll back your changes (perhaps with local copies of what you'd worked on in the meantime) and commit.

If the fact that you broke the build is ultimately due to a wider issue, then deal with that wider issue, whether by fixing it, reporting it, or assigning it.

Short term, the person who made the code-base unworkable quickly makes it workable again. Long term, the best person for the job (balancing different factors) does the job.