I just read an article about dead code. It cited Michael Feathers’s article The Carrying Cost of Code: Taking Lean Seriously:
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.
Of course it’s best to have no clutter at all. But failing a clutter-free environment, there is a great technique for reducing the risks created by this inventory.
GTD identifies the first step to tackling a chaotic mess as collection of all the open loops, the unanswered questions that each item represents. Subsequent steps organize further…to convert the inventory of clutter to an inventory of next actions. There’s still inventory, but it is vastly more meaningful and valuable.
CBRA makes clutter less expensive. It separates Rails apps into multiple “components” (gems and Rails engines) that all live within the main app's source tree. Unlike vanilla Rails development, CBRA makes it easy to reason about which code does not affect other bits. Some parts of the software are mission-critical and can receive close attention, while other parts can be coded up quickly and mostly forgotten outside whatever narrow supplementary purpose they serve.
Service-oriented architecture addresses this, but there is sizable friction involved in creating a new autonomous service. Whatever we do about the clutter problem has to be a quick and easy experience so that the right path is an easy one.
Gary Bernhardt’s video Functional Core, Imperative Shell demonstrates how organizing code well reduces the risk of sloppy, hacky experimenting without causing decay in the overall system.
(When searching for Bernhardt’s video, I ran across another page suggesting as an alternative a Reactive Shell. I haven’t explored that link yet, but the title rings true conceptually.)
So we developers can put separate concerns in separate boxes. We know we’re on the right track when
- a new feature fits inside a new “box”
- the anxiety of deploying the new “box” is low because
- we clearly understand how the outside impacts the new “box” and how the new “box” will affect the outside
- it would be trivially simple to delete the “box” when it’s no longer needed
- our list of “boxes” provides a straightforward readout of what features we’re choosing to keep around