How to keep track of SPoC for code maintenance?

Question

I am very sorry if this does not adhere to the community guidelines. I will update it based on the feedback received.

I work in a startup, and am facing a significant problem. A lot of code was written before I joined here, a big chunk of which is very poorly written and more importantly, there is just a lot of attrition, so there is just no track of code maintenance responsibility SPoC (Single Point of Contact). There is very little documentation, which furthers complicates the existing problem.

One solution, I have thought, requires people to put their names on every public methods being exposed. Furthermore, to have a tool, which could keep track of ownership of all public methods. So that, whenever a person is about to leave the project, his responsibilities can be managed effectively. Is this possible ? This can also solve some other problems, like managing dependencies for code written within the organisation.

Are there any other answers to this problem ?

Answer 1

Team project ownership

The team should own all of the code, not individual methods. And I said team project ownership not just team code ownership, because you seem to be having other issues, like documentation and handovers.

The way to fix this is with good practices like code reviews, pair programming, building knowledge and skills that span the entire code (not just silos for each developer), communication, and collaboration. This way you don't need to keep track of who wrote what. People leave, forget things, they write something and someone else changes it but their name stays on the code, so now you will go to the wrong person for details, etc. Using good practices and creating a consistent solution will allow anyone to navigate the project code.

For legacy code or existing code you need to refactor. If the code works and you don't need to change it or fix bugs in it, then it's better to leave it alone. But if you do need to change it or fix it, the solution is usually to refactor the code and make it part of the team's ownership as opposed to, perhaps, nobody wanting to touch it. You will need to add unit and integration tests in place to give you the confidence to do the refactorings without breaking anything.

If working in this startup means churning code as fast as possible and dealing with the consequences later, then the team has to own this way of working too.