This week I've been asked to write about "waste". I'm a bit tempted to just repost Meditations on the Garbage Bin, which I wrote after smoking Susan Sontag's Notes on Camp, but I think writing something fresh jibes better with spirit of the endeavour that is the Alphabet Supremacy.

Instead of writing about the unusable by-products of our lives and the ways we try to manage it, I want to explore another concept of waste that's popular in software engineering and manufacturing circles. It's a very process-oriented definition that assumes you are engaged in some enterprise to an end user or customer. It's also very simple: anything that you do or have that's not adding value for the end user is waste. The trick, of course, is what counts as value. You as maker do not get decide what counts as value, that is for the end user.

Consider preparing a dinner for a dozen guests. What really matters is food that the guests actually eat and actually enjoy, anything else is (by this understanding) waste.

The really obvious waste in this example would be food prepared that's perfectly good to eat that is not going to be eaten, even as left-overs. This kind of waste is called "over-production", and is generally obvious to spot for physical things, since you end up actually throwing stuff into some kind of bin. In software, it shows up as unused features, which are generally not so obvious.

People who embrace this "lean" way of thinking (so called because the dominating metaphor is that of keeping the meat of value while trimming the fat of waste) generally identify six other types of waste apart from over-production. Some are obvious, others less so. I'm going to pick one of my favourites: inventory. The other kinds of waste are motion (task switching), waiting (delays), transportation (handoffs), over-processing, and defects.

Inventory is the accumulated pile of raw resources or half-finished work. The idea is that all the work you've done on something doesn't count until it's actually in the hands of its intended recipients. Until then, it's potential waste. Further, the half-finished work takes up valuable space, whether it be mental or physical. You can even think of a to-do list as inventory: how much value is item 36 on the list really giving anyone?

I've recently printed out three technical papers to read. So far, I've only read half of one, so that's waste. Better would have been to print one, read it, and then print the next when I was ready for it. Instead, I've been carrying around a heavy sheaf of paper for no good reason.

The solutions to this are to delay work until the last responsible moment and to actually finish a thing when you commence it. Not "done" as in "I just need to review it once and then put it in the post", but as in "I've just got back from putting it in the post" or better, "I've just heard from them and they say I'm done".

Lean is most useful for things that are repeated, multi-step processes. Happily for its advocates, life is full of those: from cooking to stuffing envelopes. Others even apply its conclusions to personal organization systems. Most of the literature out there is oriented toward either software & startups or else heavy-weight corporates, but if you're into personal effectiveness and you aren't already familiar with the ideas, I heartily recommend that you explore them.

This post is part of the Alphabet Supremacy, a collaboration with Bice Dibley. Next week’s word is "yoga".