Code Ownership Vs Responsibility&Credit

Question

I'm having mixed feelings about a situation in my workplace. I’m getting the impression that a colleague wants to claim my work as his, but I’m also suspecting it might be unfair of me to think so.

We have a software product that needs to be tailored for each costumer. I was in the dev team that created the first version of this product with the help of an external consultant. We had very poor management from non-coder bosses and the small team was made of juniors.

The consultant enforced a mix between strong ownership and collective ownership. Most modules were supposed to be modified only by the responsible person; with very few exceptions. However, there were a few integrating pieces that needed to be modified by everyone (with everyone’s knowledge).

Afterwards, a new project has begun, with no consultant this time, and that initiates a retailoring of the product, where many modules may need very small or no modifications, while a few new modules might need to be created or removed. However, I was assigned to a different project, and is not foreseen that I would be working on this retailoring. My colleagues now have copied all the code files to a new repository, thus the commits I’ve made in the earlier project can be seen only in the old repository (which likely no one will check). We had standards for headers in the files, which included the name of the person doing each relevant modification to a file. But even with small modifications, my colleagues are “resetting” these changelogs, thus removing my name. The same goes for the documentation.

I’m not sure if I should raise a discussion about it, and if I do so, how should I proceed.

One of my colleagues has more than once presented things done with meaningful help of others as his own (he never explicitly claimed to have done it alone, but doesn’t mention whoever was not in the room) and often says “We did A and B” when he should have said “Joe did A and B”. So there is a trust issue on this matter.

The concern I have is that all code I’ve developed in the past years will now be seen as if it was fully developed by my colleagues. The boss having very little visibility and no interest in managing people does not offer a good counterbalance to this concern. I understand the code is the company’s property and not mine, but the impression is that I’ll lose all credit I should have from developing it within the next year. This is more critical on how I would be seen by new employees or by (possibly) a new boss outsourced by the company.

Answer 1

I’m not sure if I should raise a discussion about it, and if I do so, how should I proceed

In this case you don't do anything.

As you mentioned, the code is the property of the company.

However, credit and/or responsibility for is very different. Ultimately, this is up to your manager to recognize who has contributed what. A good manager with some technical background (doesn't have to be an ex coder) will recognize who their key contributors are and will reward them accordingly. A not so good manager, well, won't.

With that in mind, I would not worry about this much. Contribute to your team, continue to grow your skillset ( so you are marketable outside the company ) and carry on with your work.

Answer 2

Okay, sorry, but I'm going to answer this as a frame challenge.

You shouldn't bring up a discussion about it, because you're focusing on the wrong issue. The big problem is that your company is trying to move into a 'Silo' model where each piece of code has a steward that is responsible for edits to it.

No. You should be striving for cross knowledge. The Flooster system shouldn't be "Alice's" - it should be a system that multiple people are comfortable editing/compiling/deploying. The Ribble code library shouldn't be "Bob's", anyone in the group should feel comfortable making improvements to it. Because imagine if Alice or Bob leave the company, get hit by a bus, are promoted, whatever. Suddenly you've got swaths of code that nobody feels comfortable about taking care of. After all, those code libraries were Alice's/Bob's.

If I were in your shoes, I'd say something like this to the manager:

I'm a bit worried about cross-training in the group. Since that consultant came, I'm worried that we don't have enough people that know enough of the codebase. I mean, Charlie's been working on the XYZ system - and he's the only one that's touched it. What happens if Charlie leaves? Nobody else knows that system besides him. Same thing with Diane and the ABC system.

... because, honestly, your value to the manager isn't "What code did you write the original release for?" but "What stuff can you help us with moving forward?" - and being able to keep the existing systems running is a huge part of that equation. I'd much rather have an employee that knew all the systems and could make modifications/enhancements to any of them, than one who had only wrote the original version of a subset of them.

Answer 3

We had standards for headers in the files, which included the name of the person doing each relevant modification to a file. But even with small modifications, my colleagues are “resetting” these changelogs, thus removing my name. The same goes for the documentation. I have to go back and look at the blame or logs and tell the person you got the wrong guy. I did a mass delete of my name from the change log before leaving though.

At my last company we had this policy although later down the road we moved to svn then to git. The problem with this is nobody uses "blame" (I think now it's called praise or something). So when a problem arise, they look at the header change log and just so happens my name is one of the people who modified the file although the file has long since taken new shape or copied to another file.

With that said, I think he might be trying to help you. People copy and paste the header, including all the names to a new file. Now your name is on a new file. So rather than people coming to you asking you questions about a file that you no longer control, now the new people will get asked.

Even if for sinister reasons, no manager is going to look over all the files on a system and determine if you modified it and got the proper credit. In the inverse, what's stopping you from being the bad actor and going into every file to add your name to insure you get credit for things you never did? So I think this concept is flawed. The real question is what's your manager doing to make sure you get credit? During review time is your manager bringing up stuff you did and writing it down? If not, perhaps talk to him about it or find a new place where you are appreciated in the way you feel best.

Answer 4

The problem is not that individual X claims code is theirs when it's half yours, or that artefact Y is being overwritten by artefact Z and thus deleting the trail. The problem is that you are working in a company which cares about who wrote the code.

So long as that is the case, you, and others, will experience these problems. You may one day fix a load someone else's code and have it attributed to you, much to a new junior's dismay.

Parallel world

In the company I work for we have no immediate visibility of who wrote the code, nor does anyone dig through git to investigate who is responsible when we find bad code, nor do we give people a hard time when we discover the bad code is theirs (Perhaps they copied it from someone else and tweaked it to make a deadline knowing it was ugly code, but that was still the best decision at the time. Perhaps they told someone they were doing this and planned to refactor but got pulled to another project etc...) Besides, does the responsibility lie with the junior who wrote the code, or the senior who let it through code review?

Needless to say, we have none of the problems you talk about. It's not utopia, but lack of individual attribution does not cause any quality problem that I see, everything goes through code review, we unit test quite extensively, and have dedicated testers.

Conversations

I think you should initiate a conversation about the value of caring about who wrote what code in the first place, and whether this is beneficial or detrimental to the company.

Isn't there a chance that people won't refactor code because it doesn't have their name on it? Doesn't this create a toxic every programmer for themselves environment? Doesn't this denies the codebase many fixes it could otherwise get? What about people who've left, or who know they will be leaving soon? What tangible benefits are gained from retrospective blame?

If you can initiate a conversation about this, you might find that the net effect of code ownership is not as good for the company as it's held to be.

Answer 5

To offer a counter perspective: Unless I'm misunderstanding, that sounds like professional behaviour that would be considered normal, even expected, in the companies I (used to) work.

1. Rather than tooting his own horn, he's presenting all work as a team effort ("we" includes everyone who contributed to the code).
2. He's applying "boy scout principles" to get rid of redundant and outdated comments for files he needs to modify for other reasons. (You do use version control, right?)

Even if that goes against the usual principles at your company, it might be what he's used to from previous jobs. I doubt there's any malicious intent behind it.

How about you simply ask him for his reasons? You might be surprised.