The more I think about it, the more I am against strict code ownership ("my stuff = my commits"). I mean - yes, there has to be someone who 'owns' the piece of functionality (for the sole purpose of supervision, roadmapping, etc.), but the more people put hands on it, the better. And the reasoning I have is not code-focused (related to quality, tech debt, etc.), but people-oriented.

I'll be very explicit & straightforward:

  1. the more code programmer interferes with (in general, not in the particular moment of course) the better
  2. dealing with the same module / single application for years not only stops developer's self-development, it makes him/her regress, preserves bad habits, suppresses motivation & innovation -> it CRIPPLES her / him
  3. Open Source model is not only for non-commercial, geeky projects on the web. It can work as well internally within organizations (of course some pre-reqs have to be met)

The usual way

How many times have you heard:

("Team A created this some time ago, so sadly your proposed change has to wait until they have some spare time. They may get offended if we asked someone else to do it."

"This piece of code is very tricky, just leave it to B, he's the author & the only person who can read through it."

"That has to go to Team C - they've done 438 last modification in this module, so they will make adjustments in a shortest time."

At first glance, it all makes a lot of sense. But if you give it more consideration - it's a trap, and a very dangerous one:

  • strict code<->people binding siloes the knowledge, reduces development agility, impairs communication (by reducing the need of discussion & knowledge exchange) - go against that instinct, make the first step to actually spread the "tribal" knowledge & provide different perspectives to help solving actual problems

  • fighting off paternal / maternal feelings against the code you wrote is one of the first (& required) steps to actually become a professional - code & its nursing can't be the goal itself, it's an unhealthy instinct that may lead to even more sinister behaviours (Not Invented Here syndrome, code duplication, needless code re-writing & huge issues with troubleshooting) & what is the most important - it's contrary to the value-orientation

  • the worst thing about the comfort zone is that usually you lock yourself within absolutely unconsciously - without realizing at all. Sadly, in software development consequences are more severe than in other cases: programmers can't let themselves stand still, they need to develop to increase (or at least maintain) their usefulness, skill & "market value" and how are they supposed to do that if they are stuck in the same project (or similar projects for the same product) for years - same architecture, same files, same classes, same duties everyday -> is it still a creative work or a conveyor belt?

I've met some people arguing that there's a limit on code developer can comprehend and move within easily - honestly, I disagree. They key-point in software development is not to learn the code by heart - it's to be able to understand it & navigate within.

They will break it

Of course there's a whole discussion about quality (in context of ownership):

Supposedly the team that has the most experience with the code is the one who's most likely not only to do the changes better (with the slightest chance of screwing things up) but also to improve overall code quality, reduce tech debt, etc. Sadly, it's another mental trap - instead of raising the fences & sealing the gates, improve the transparency & automate quality assessment. It should be main owner's responsibility - make everyone able to contribute (in a healthy way).

If particular dev (or 2, or 3) feel that the code is their internal matters (because it's only them who have to deal with it / fight it / maintain it) - what's the incentive to make it readable & maintainable for all?

This is exactly the model OSS is so heavily utilizing: Pull Request model, test automation, continuous integration (& inspection), openly accessible SIR dbs, etc.

It really strikes me when I hear some people complaining: "Hey, why do I have to modify that? Someone else made it - tell HIM/HER to do it then.". My spontaneous answer is:

"You're welcome."

Pic: © puckillustrations - Fotolia.com

Share this post