Archive for May 2009

Lean at Home Again

May 9, 2009

I got a nice comment from Mark Graban who posts some cool quality oriented stuff.

I appreciate your efforts to apply Lean principles at home.

A few questions:

To point 3, it takes more electricity to cool an empty refrigerator or freezer. Are you considering energy costs? That’s probably nit picking

To point 5, this only holds true if stores are near by. You wouldn’t drive 15 minutes to Wal-Mart to buy a single can of soda each time. Sometimes inventory is OK if it keeps total cost (including transportation cost) down. The math would work out differently if gas were $5 a gallon.

Leftovers are OK as long as you consume them. The energy cost of roasting two chickens at once might be the same as roasting one.

Just being a pest with my questions… keep us posted on your efforts!


I’m terribly flattered that someone with real understanding about quality would take notice of my trying to adapt quality stuff to my home life. As a result of writing Lean at Home I’ve been able to converse with two experts on quality about using the mindset and practices at home.

First of all, I live 5 minutes drive to Meijer, Walmart, and a pretty good health food store. My commute, while only 20 minutes, makes stopping by the store before coming home, or making a quick trip out practically inconsequential. Plus, I enjoy taking a kid or two shopping with me, so making the occasional trip is almost a win.

Now about electricity in the fridge. By shooting for empty (not acheiving it yet, by any stretch, just shooting) I’ve probably saved $400 a month. So I’m not really excited about spending $400 extra in wasted food and stuff to save $12 in energy. Not that Mark meant that, just saying, I’m the guy on the line here, so I’m sharing…

The way I see it, and I’m open to being wrong about this, is that continuous improvement is about elephant eviction. The people working the lines, writing the code, or cleaning the floors, know what the real problems are, the elephants in the room. I’m that guy on the line. Continuous improvement, as I see it, is about evicting the first elephant, and looking for another. I’ve never worked in an office where there weren’t a few elephants hanging out. You’ve probably seen those huge waste pits known clearly to everyone except management, who perpetuate them. Maybe there are workplaces where the elephants are gone and they are on some truly high plane of organizational maturity. I’ve never seen it myself.

That said, my home has a few elephants in it.

I have 5 kids; 3 have autism. I have to buy a lot of organic food and a ridiculous amount of hard to find supplements, etc. The kids are showing improvement with the nutrition and treatments recommended by their doctor. Yay. It’s expensive.

Elephant 1: I don’t get to overbuy cheap food. I have to overbuy organic. Throwing away a half consumed organic bulk frozen item to make room for new a new organic bulk frozen food item was a constant problem for us. That’s the waste we set out to solve.

Energy isn’t a big problem for us. We have a very efficient heating system, and Indiana cooling is more about humidity control than brute force cooling. It’s just not a big problem.

Elephant 2: The house gets really messy really easy. This is what we are working on right now. Our autism kids are not the classic Oprah autism tv special toy stackers. No. That might be helpful in isolation. While like any red blooded autism kids they can certainly appreciate a package of 12 practice golf balls. White, uniform, all alike, they don’t get lined up end to end at our house. No. Ours persevate on scooping them up and running them over their hands and legs. The uniformity is glorious. But when it’s over, they get left strewn about wherever they were, where they will eventually get broken. Meanwhile someone is breaking into the salt box. And we don’t yet have the mental capacity and focus for a proper family cleanup time. Rats. So we’re having to come up with some systems and just plain less stuff around so we can make the best use of the stuff we have.

Anyway, at home and everywhere I’ve ever worked, it’s been elephants all the way down. So I had to chuckle at the idea of worrying about energy consumption of an empty fridge. But hey, Mark asked the guy doing the work, going to the gemba, if you will, which is the right thing to do. And when you do that, you always learn something actionable.

More on Clever is Good

May 4, 2009

When I first went about criticizing the use of the word “clever” describe bad code, I thought using “clever” to mean “bad” was silly and self contradictory. Ironically clever, if you will.

Having hassled it out with far greater minds, I’ve changed my thinking about why bad code shouldn’t be called clever. (See the comments.)

The problem with describing bad code as “clever” is that it doesn’t describe the code at all.

Code is words. Words can’t be smart. They can’t think on their own yet. At best they tell a clear story.

And words are only at their best when they are woven by good writers. When I say, that’s a “good” story, I’m not wondering how words wove themselves into such a great story. I’m simply complimenting the writer of the story for a job well done.

When I say a story is “bad,” I’m saying that the writer failed.

When we look at work and criticize it with words that are negative human attributes, like clever, bad, lifeless, or lazy, we are criticizing people.

It’s a free country. Except for me, and the other people who, like me, have been at this work for pay thing for 10 years. We’re supposed to know better. We’re supposed to know that problems at work are always systemic. We’re supposed to know to criticize the system. Maybe criticize management, in moments of self indulgence. But only for the purpose of fixing the system. (Writing this brings pangs of regret. I have screwed and continue to screw this up daily.)

We’re prodding our teams to write unit tests and do pair programming and have retrospective meetings in an effort to fix dysfunctional systems.

We’re supposed to be the champions of continuous improvement. That means identifying code problems as code problems. Then we translate code problems into system problems. Then we fix the system.

We’re supposed to know that nothing will damage this effort more criticizing the intentions of the people working, often without power, within that imperfect and maybe dysfunctional system.

We don’t criticize people. We’re supposed to know better. I’m supposed to know better. I so wish I did.

Deming said “The problem is at the top; management is the problem.”