Code as Inventory

I recently read a ten-year-old blog post by one of my software heroes, favorite Twitter follows, and author of Working Effectively with Legacy Code: Michael Feathers. The post, called The Carrying-Cost of Code: Taking Lean Seriously, struck a chord with me.

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.

…

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.

In my career I've heard people brag about teams that "cranked out code" and such phrases. I cringe at the idea that bringing new code into the world is inherently a good thing, and doing it really fast is an even better thing.

On top of the cost of compiling it, running unit tests against it, cloning it from a repository, and shipping it in DLLs, there's the conceptual overhead of keeping around code that we don't need. Every time a developer has to read the code, scroll past it when searching for something else—in fact every thought that occurs in relation to it, in perpetuity, is waste.

As Feathers concludes:

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.