I've spent the past 8 years or so looking at ugly code. This isn't uncommon in software development but in my case, I've been looking at different ugly code developed by different teams every couple of weeks. One question that people often have is whether to refactor or rewrite. It's never a simple call. Usually, this is because the reason that people want to rewrite code is because they don't understand it. Yet, rewriting code often requires us to understand it well enough to proceed with the rewrite, especially if there are existing customers who depend on all of the nuances of behavior that the system has consistently exhibited.
When you see enough of this, it's easy to take a bleak view. There are many places in the industry where existing mountains of code are a drag on progress. The worst thing is that quite often organizations are so close to the problem that they can not see its full extent. When business sponsors receive the cold-shoulder enough times when they want particular features, they stop asking. They have learned that "changes to X are expensive" and they gradually shape their business in different ways. The effects ripple out from there. Younger organizations without as much software infrastructure often have a competitive advantage provided they can ramp up to a base feature set quickly and provide value that more encumbered software-based companies can't. It's a scenario that plays out over and over again, but people don't really talk about it. When Agile came around there was a lot of talk about flattening the cost of change in code. With good practice, you can do quite a bit of that. However, entropy happens. Older codebases are typically harder to change.
A few years ago, I was telling some friends about an experiment I would love to run. I'd like to have code base where every line of code written disappears exactly three months after it is written. If you were able to get past people gaming the system by copying code someplace else and then copying it back in when it was deleted, you'd have a very interesting set of constraints. Developers would be rewriting code constantly and they'd develop insights into ways to rewrite the code more compactly and (hopefully) more understandably. Perhaps more importantly, the business would have to make very serious tradeoffs about the features. If you are limited to a smaller number of features (because code keeps disappearing), you have to make sure that the ones you keep are really the ones which are making you money. I have the suspicion that a company could actually do better over the long term doing that, and the reason is because the costs of carrying code are real, but no one accounts for them.
Recently, there's been a strong move toward Lean in the industry. The roots of Lean are in manufacturing - the Toyota Production System, etc. I like some of the concepts, but I remember being shocked early on by what the lean community considers to be "inventory." In manufacturing, inventory is a very clear concept. It is the extra stuff hanging around.. the things that partially done and queued for the next bit of work. In Lean Software Development, requirements are often seen as inventory. If you spend a lot of time elaborating requirements for features you are not going to work on for a while your process isn't streamlined enough. That's fair, but I think that the brutal reality is that we have something much more tangible that we can see as inventory: our code.
Let's go back to manufacturing. If you are making cars or widgets, you make them one by one. They proceed through the manufacturing process and you can gain very real efficiencies by paying attention to how the pieces go through the process. Lean Software Development has chosen to see tasks as pieces. We carry them through a process and end up with completed products on the other side.
It's a nice view of the world, but it is a bit of a lie. In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can't expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention.
No, to me, code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.
I think that the future belongs to organizations that learn how to strategically delete code. Many companies are getting better at cutting unprofitable features in their products, but the next step is to pull those features out by the root: the code. Carrying costs are larger than we think. There's competitive advantage for companies that recognize this.
