Return to Answer

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code.

Ultimately, the team owns the code. But for all of the reasons you mentioned, our software team has designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code.

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. In my working environment, each person is assigned part of the code to be primarily responsible for; that person becomes the "consultant" for that particular section of code, since he wrote it.

There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code. It's difficult to get accountability when you have a half-dozen people hacking on the same bit of code.

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code.

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. In my working environment, each person is assigned part of the code to be primarily responsible for; that person becomes the "consultant" for that particular section of code, since he wrote it.

There is, of course, nothing preventing other team members from applying a fix. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code. It's difficult to get accountability and responsibility when you have a half-dozen people hacking on the same bit of code.

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. In my working environment, each person is assigned part of the code to be primarily responsible for; that person becomes the "consultant" for that particular section of code, since he wrote it.

There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code. It's difficult to get accountability when you have a half-dozen people hacking on the same bit of code.