Hacker News new | ask | show | jobs
by jordoh 4904 days ago
There are a couple assumptions here that seem like they could be pretty faulty:

1. Whoever touched a line of code last is most familiar with that line of code. I just moved a method to a different module, so following this assumption I am now the person most familiar with every line contained in that method.

2. The line of code triggering the exception is actually at fault. I just changed a value in a configuration file and it triggered an exception off in some code that creates a network connection - code I've never touched.

How faulty these assumptions are probably varies pretty wildly from organization to organization.

1 comments

In your first example: you are not necessarily "the person most familiar", and I don't think that's the assumption. You are, however, likely (to some degree) to know who should be contacted to resolve the real problem.

In your second: If you changed a value in a configuration file and it triggered an exception somewhere, many people would say you are at fault for not testing your change.

Most places I've worked there's a simple rule: whoever last touched the code that broke is responsible for getting it fixed. That isn't meant to be taken literally in that I must actually make the code change myself. It means that it can be assumed that if I'm touching some code, I'd better be familiar with the code I'm touching. If that means I delegate the fix to the original author, then great: It's still getting fixed. If I can delegate to someone who's better suited to make the code change, that's OK too. If not, I make the fix. In any case, If I'm changing a line of code, you can assume that I'll know what action to take if that change breaks something. If I don't, I shouldn't be allowed to make the change in the first place.

In your second: If you changed a value in a configuration file and it triggered an exception somewhere, many people would say you are at fault for not testing your change.

Exactly. However, the exception will likely be thrown from somewhere in the network stack, not from a config file, so whoever last modified the error checking code in the network stack will get an email instead.