Open Source as a style of living. For everyone.

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...

3 years ago

Latest Post Mixing warsaw.ex by Sebastian Gebski

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:

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 -

Sebastian Gebski

Published 3 years ago


Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.