Contained clutter

Every line of code is that much more technical inventory that carries risk and management burden. How can we make efficient progress without impeding our delivery of features?

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

Setting WIP limits

Applying Lean methods to optimize the flow of a system, one encounters advice to limit the work in progress (WIP) to help keep things moving. I've wondered whether there's some simple way to take an educated guess as to what WIP limit would be appropriate. I found such a strategy (sources below). 













The number of arrivals and departures from a given state should be equal. If they deviate from each other, tuning the WIP limit can bring them into line with each other.

I know enough to know that my understanding of lean is of the "enough to be dangerous" variety, but I'm pretty sure that in summarizing this I've avoided the pitfalls described in these sources:

Deleting in batches from PostgreSQL in Ruby

PostgreSQL doesn't support LIMIT in DELETE queries. But it's a bad idea to delete huge numbers of records at a time if the operation will be more than a few seconds. So deleting in small batches can be done like this:

DELETE FROM mytable WHERE id = ANY(ARRAY(SELECT id from mytable WHERE myfield = 10 LIMIT 10))

To use this code from ActiveRecord in Ruby and get the number of affected rows:

rows_affected_count = ActiveRecord::Base.connection.execute(query).cmd_tuples

You can do this in a loop to keep the queries moving through the system without slow queries choking things up. When rows_affected_count is less than the size of the batch, you're done.