Hacker News Reader

Comment by greenrd | Hacker News Reader

Sometimes code ownership means something slightly stronger, i.e. that no-one else has the authority to change the code. It's fine for a team to own code in this sense, but it's really bad news if an individual owns code. This is one of the things that Scrum tries to prevent, by not pre-assigning tickets/cards.

View on HN

This kind of dilution of respnsibility essentially guarantees mediocrity and low satisfaction. It’s bad news if an individual doesn’t own code and/or large projects over that code. Treating engineers as interchangeable cogs who can be reallocated between bite-sized tasks on a whim misunderstands the nature of software development and is employee-hostile in a way that you’re unlikely to get away with in this labor market.

There is an alternative problem where there is no strong ownership in place, but code that should be changed doesn't get fixed or updated because nobody owns it.

To get back to the point that I was trying to emphasize, a big problem with software development organizations is that often they do not own their software development process, making it essentially out of anybody's control.

I guess in a scenario like that upper-level management (e.g. the CEO) could try to take ownership of the process, but that's unlikely to ever work out well.

But having one person own a certain forces resposibility and when the team grows you have two people own that piece or 10 as budget permits.

Reply on news.ycombinator.com