The little legacy code that could: a fable of software ownership

Well, I think the article not so great on this one. There is unclear ownership because management thinks that software is finished at some point. They think in terms of large, vague blocks of functionality and have difficulty understanding things at a finer scale. When requests come in from users of the software, they are often ignored by management because none of the requests are large enough to fit into their large, vague ideas. However, all the requests put together add up to a very large impact. The result is that the legacy code gets neglected and new greenfield projects get the attention. Because nobody works with the legacy code, it becomes strange and foreign. It is built with older technology which is no longer sexy and is boring on your CV, so the movers and shakers in the IT group tend to avoid it. It's not code ownership that's a problem -- the whole company washes their hands of it.

In terms of code ownership, you can run your group in a number of different ways. I've seen projects with code ownership work and I've seen projects without code ownership work. I vastly prefer the latter, personally. As long as you are churning the code regularly, a lack of code ownership means that internal conflicts about how things should be designed are forced out in the open. They don't fester for years and years, where groups of developers end up saying, "I can't work with that person. They are crazy." You have the conflict early when it doesn't have such a large impact and you sort it out early (Note: some people are just inflexible -- if you find that kind of person, knowing about it early is also good. You can deal with it).

When you avoid code ownership, you are also forced to have code that is clear for your entire group. For example, if you have a single person and they work in isolation, their code may be impenetrable to the others. But if each person in the group has to work on the code, code that most people don't understand has very little chance of surviving. Overall, I find that staying away from code ownership results in considerably more maintainable code.

However, there are clearly advantages to code ownership as well. One shouldn't snub their nose at the benefit of being able to see a piece of code and say, "I wrote that". Having ownership makes it easier to have pride in your work. It can be a very motivating factor. If you have people on your team who are feeling disconnected and don't feel like they are personally making an impact on the group, giving them a little piece of code to own can be very good for them.

Similarly, sometimes you don't have a choice for your team. Sometimes you have a team of people who just don't work well with each other and there is nothing you can do about it. Partitioning the code and allowing these people to keep their distance may be the only thing you can do. Ideals are great and if you can achieve them, it's wonderful. But you have to be conscious of reality. People are people.

I could go on and on, but I guess my point is that very often I see remarks like the one you made that seem to take a very superficial view of things. There seems to be no effort made to understand why other people have a differing viewpoint. Of course, you also get fan-boi style postings of, "The-new-hotness is the best thing because reasons" which are also unfortunate. Usually the truth is somewhere in between.

Yeah. Stated another way, building new stuff is more highly valued than maintenance. Even though the new stuff may fail, or the maintenance may end up requiring more skill than building.

This is what our industry values; make your choices accordingly. It’s also one reason for the perception that developers are more obsessed with new shiny things than learning their older counterparts. We’re incentivized to act that way.

You can’t only look at your work in terms of what is most valuable for the business, because that may turn out to conflict with what is best for you and your career.

Even at my current job in a startup, 90% of the code I own can be considered legacy.

The startup is 7 yo, I joined almost 2 years ago.

The gap between old and new features is enormous .. and it will take years to reach some cohesion.

I don't think it contradicts the point.

When you have a legacy system that "sits in the corner" earning money, you're [the company] paying engineers to retain their services in emergencies. Features get added too, if you're interested in keeping or gaining customers. So construction cost as a proportion of total cost does trend to zero.

The company/stockholders doesn't care about hot new technologies. They care about revenue. Customers don't care their software is written in this or that framework or is powered by deep learning. They care about stable, usable, useful apps. Businesspeople know this. Many engineers do not. I think that disconnect causes much strife in tech businesses.

I think one of the reasons why it's such a conundrum is because software development as a practice is just now getting to the level of complexity where large groups of people have collaborated over a large codebase over a long time.

One of the problems that the microservice architecture is trying to solve is by making a a large software entity a collection of smaller easier to manage entities. It's like single cell organisms evolving to multicell organisms...each cell becomes smaller and simpler and more specialized and replacement of cells becomes easier and allows the overall lifeform to "scale" and become more complex.

Mature software companies have gone through this transformation multiple times already in the form of, n-tier, SOA, microservices, and now serverless architectures. This is all part of a natural progression of making individual components simpler, the overall structure more granular, and as a result more resilient. This resiliency opens up new capabilities to scale a complex system.

My long winded point being that legacy software will always exist yes, but each piece of legacy software is already getting smaller and more granular where rewriting it will eventually be a more continuous operation of refactoring small things--kind of like skin cells falling off your body or hair falling out.