5 ms·

This product reinforces a mindset that I find harmful. Where I work, teams of developers are responsible for products -- we all own the quality and robustness

by lbarrow 14y ago

This product reinforces a mindset that I find harmful. Where I work, teams of developers are responsible for products -- we all own the quality and robustness of our product's code. If the application is broken, why would you only email the person or pair who wrote the particular line of code that excepted? Am I supposed to pretend broken code is not my problem unless I personally wrote it? Development is a collaborative activity. If a product is broken, the whole team needs to know, so the whole team can fix it.

Zelphyr 14y ago
I don't disagree. However, it seems like the idea with Squash is to give the person who is most familiar with that code the chance to fix it quickly. Fixing a bug early in development is my problem. Fixing a bug in production is all of our problem. I think Squash encourages the former in order to mitigate the latter.
- jordoh 14y 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.
  - ithcy2 14y ago
    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.
    - DougBTX 14y ago
      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.
tumultco 14y ago
I do not disagree with the sentiment; it is useful to immediately know if there's been a bug introduced that might slow down your work and you may be in a good position to offer suggestions to fix. But also consider: - If the bug is a regression it may stem from the author's misunderstanding of the codebase. By being the one to fix the bug they have a chance to learn correctly how it works and reduce future mistakes. - The original author of the bug was just in the code and can likely most efficiently fix it since they are recently familiar. - It would be wasteful to have two people working on the bug at the same time (though bug policy can also help with this). - On a large project there can be lots of noise which does not affect you, especially if the project is well compartmentalized. - Taking responsibility is always a good thing! It is only toxic when people start pointing fingers and shifting blame instead of helping out. As a "component owner," I personally like to fix my own mistakes so I can learn from them.
jmileham 14y ago
There's power in the concept of chain of custody. I agree that you don't want to associate negativity with this stuff, but identifying an owner who understands the code and whose job it is to fix or find the right person to fix has huge merit. I've worked on too many projects where the issue tracker balloons due to diffusion of responsibility.
Bockit 14y ago
Perhaps a way to configure it to work in that environment may be: Bug email gets sent to the dev it determines responsible, and if they 'sit on it' it gets sent to the whole team. With an appropriate sit-on-the-email period of a couple of hours, or a day. If it was really critical the dev in question could easily escalate it anyway in that kind of environment. This should give you the contextual advantage first, and then collaborative advantage very soon after.

by lbarrow 14y ago

Zelphyr 14y ago

I don't disagree. However, it seems like the idea with Squash is to give the person who is most familiar with that code the chance to fix it quickly. Fixing a bug early in development is my problem. Fixing a bug in production is all of our problem. I think Squash encourages the former in order to mitigate the latter.

jordoh 14y 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.
- ithcy2 14y ago
  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.
  - DougBTX 14y ago
    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.

tumultco 14y ago

I do not disagree with the sentiment; it is useful to immediately know if there's been a bug introduced that might slow down your work and you may be in a good position to offer suggestions to fix. But also consider: - If the bug is a regression it may stem from the author's misunderstanding of the codebase. By being the one to fix the bug they have a chance to learn correctly how it works and reduce future mistakes. - The original author of the bug was just in the code and can likely most efficiently fix it since they are recently familiar. - It would be wasteful to have two people working on the bug at the same time (though bug policy can also help with this). - On a large project there can be lots of noise which does not affect you, especially if the project is well compartmentalized. - Taking responsibility is always a good thing! It is only toxic when people start pointing fingers and shifting blame instead of helping out. As a "component owner," I personally like to fix my own mistakes so I can learn from them.

jmileham 14y ago

There's power in the concept of chain of custody. I agree that you don't want to associate negativity with this stuff, but identifying an owner who understands the code and whose job it is to fix or find the right person to fix has huge merit. I've worked on too many projects where the issue tracker balloons due to diffusion of responsibility.

Bockit 14y ago

Perhaps a way to configure it to work in that environment may be: Bug email gets sent to the dev it determines responsible, and if they 'sit on it' it gets sent to the whole team. With an appropriate sit-on-the-email period of a couple of hours, or a day. If it was really critical the dev in question could easily escalate it anyway in that kind of environment. This should give you the contextual advantage first, and then collaborative advantage very soon after.