3 ms·
In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people wou
by curtis 9y ago
In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people would expect. If someone "owns" a subsystem, they are not just responsible for it, they also have the authority to modify it, and they understand it well enough that they can modify it. Most often (at least in startups) the owner of a subsystem either implemented it or implemented substantial portions of it.
OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example.
Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to.
Your Agile software development process isn't going to work well if you organization doesn't fully own it.
- greenrd 9y agoSometimes 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.
- curtis 9y agoThere 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.
- closeparen 9y agoThis 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.
- wolco 9y agoBut 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.