1

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 ?

Improve this question
10
  • The main inspiration for my proposed solution comes from git annotations, wherein it is mentioned which person edited a particular line of code in any file – cyphx Jul 23 '20 at 8:06
  • 3
    This is one of the features of source control. If you don’t have it already, implement it. That’s more of an engineering concern than a project management one, though. – Todd A. Jacobs♦ Jul 23 '20 at 11:12
  • 2
    Seconding Todd's comment. My immediate thought was 'git blame'. My suggestion would be to research source control annotations (e.g. git blame) and then if you have questions, ask it on the relevant stack. This has nothing to do with pm, so voting to close. – Sarov Jul 23 '20 at 18:10
  • 1
    @cyphx, you don't always have a person who can answer questions about the code they wrote. It happens, it's not a tragedy. Developers can read, understand and test someone else's code, at some point another developer will start owning it. Occasionally things will break, then they'll get fixed ;) – Stanislav Bashkyrtsev Jul 24 '20 at 7:57
  • 1
    This underlying problem is very likely to be already addressed in I've inherited 200K lines of spaghetti code — what now? – Tiago Cardoso♦ Jul 28 '20 at 10:41
3

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.

Improve this answer
2
  • How do I start solving the problem for old/bad code? We are incorporating lot of practises that you have mentioned, but it can't be done for code that has already been written. Plus, a lot of it was written by someone without any significant experience writing code, like some person who has just graduated out of his bachelors and started writing code. – cyphx Jul 23 '20 at 8:50
  • 2
    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. 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, maybe, 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. – Bogdan Jul 23 '20 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.