Talk About Quality

Recently I found an excuse to dust off some old lab books of introductory science experiments. They were the curriculum for a 9th grade Physical Science I class at my high school; I wrote them as a summer job during college. I didn’t invent the experiments. Rather, the head teacher gave me outlines, and my job was to try them out and make sure they would work, so that prospective students wouldn’t get frustrated and turned off by science.

The excuse was a friend, a scientist, who is meeting a public service requirement of her studies by volunteering to teach science to schoolchildren, and to their teachers. I offered my science course as possible material for her classwork. As we looked over the experiments, we doubted a bit how even 9th graders might learn from them, or be as excited about them as I was when I built and tested them myself. Sure, the projects were easy, and they had worked. But would the experience of building these projects — static electricity demonstrations, electromagnets, motors — be enough to convey the principles behind their operation? Would the kids see the point?

Yesterday I was in the kitchen preparing a simple lunch of tacos and beans. Washing and cutting lettuce, chopping an onion, peeling a cucumber, grating cheese, warming the beans with some tomato sauce. In the quiet afternoon, I couldn’t help noticing the crunch of the knife through the lettuce. Or wondering how best to preserve the other half of the cucumber, now leaking water from its open end. And why do we grate cheese? So much science, here in the kitchen!

Now with the internet, you can search “science in the kitchen” and get pages and pages of websites with all sorts of neat science projects in the kitchen. Let alone YouTube with some pretty exciting and dangerous experiments. (Be warned!) I have no doubt that school science textbooks have taken this to heart and now include experiments that relate to the real world. And yet, science enrollment declines.

Even with the best of intentions, popular science experiments in the kitchen won’t do it. Science is not in school, nor is it in the kitchen. Science is not an activity, but a way (just one way) of looking at the world and making sense of it. What excited me in science class was not the sitting and listening to the lecture. It was making the connections with daily life outside class, and enjoying the beauty of the natural world with new understanding.

Those understandings could come from things as simple as basic cell structure in biology. There’s lots of water in a living cell, so when you peel and cut a cucumber, it gets wet. Or as complex as thermodynamics. One college winter, I learned that there’s really never a flow of “cold”, but only heat transfer. For a good month after that, climbing the steps to class, I would grasp the banister outdoors, and instead of feeling cold, I felt the heat flowing out of my hand into the metal. These experiences are what brought me back to study even more.

Science teachers have to have and share that excitement. If they’re not science experts themselves, no matter. They are learning adults, who can build their own understanding and catch the excitement from science mentors. The key has to be in giving the right answer to the question so many students ask: “But what is this good for?” The wrong answers are the allegedly practical ones — advancing technology, getting a job, or passing the test. The right answer, the one that should guide science teaching, and bring the kids back to class, is “Because the world around you is beautiful, and science gives you eyes to see it.”

Recently I read an article by Norman Balabanian (“On the Presumed Neutrality of Technology”, IEEE Technology & Society magazine, reprinted Winter 2006, pp. 15-25; originally published in 1980), where he addresses, among other things, the popular claim that people choose new technologies out of free choice. That if we use a technology, whether it be a car, or a refrigerator, or permanent-press clothing, we freely choose the benefits, and have accepted the costs. In several examples, Balabanian shows that we do not. We live modern life as part of an interlocking, consumption/profit-driven system which requires us to accept most of the new technologies, or starve.

I decided to do a small experiment in the household, to see up close what Balabanian was talking about.

The Experiment

I set out to collect and put aside all the food packaging that our family opened and threw away as part of our meals at home for one week. Not paper plates or napkins, or non-food trash such as newspapers. Just the containers that our food comes in. My kids wondered at first, but after a day or two I convinced them that even after school people still learn, and this was my self-assigned science project this week. As material rapidly piled up, I cut off “data” collection at 4 days.

What did I find?

I collected a half-full garbage bag of paper and cardboard, similar of plastic bags and bottles, and a few metal cans, for a total of 1 kg of waste material. By weight, the packaging was a bit less than 4% of the food net weight. Not much at all, but I was not concentrating on waste vs. recycling.

Rather, I was looking at the question: have we freely chosen to buy our food packaged?

Looking at the list below, I have to say “no”. Very few of these foods are available for purchase either at our corner grocery, or our large supermarket, without the packaging (i.e. take in your own container).

Reminds me of a cynical saying we used to have in high school: “You have a choice … and it has been made for you.”

The Challenge to Innovators

Don’t tell me how to recycle these materials. (We do already—as much as our city provides for.) That’s more forced choice: take the food in packages, and then recycle the packages.

Instead, suggest ways that we or the food distribution system could change so that we could eat our (reasonably) healthy diet without all the packaging in the first place.

Appendix 1: Four Days of Food Packaging

Food Amount (g) Type Wrapper Type Comments

Cheetos™ 55 Prepared Plastic Silverized
Pudding 330 Prepared Plastic
Fruit 1000 Prepared Plastic Styrofoam
Flour 2000 Prepared Paper
Cola 3000 Prepared Plastic
Milk 3000 Raw Plastic
Cereal 1200 Prepared Paper Waxed cardboard
Cereal 0 Prepared Plastic
Cottage Ch. 250 Prepared Plastic
Sugar 1000 Raw Paper
Potato Chips 50 Prepared Plastic Silverized
Eggs 1400 Raw Paper Cardboard
Soda Water 1500 Prepared Plastic
Smoked Salmon 100 Prepared Plastic
Granola 500 Prepared Plastic
Brown Sugar1000 Raw Paper
Yogurt 450 Prepared Plastic
Fruit Juice3000 Prepared Plastic
Margarine 2000 Raw Paper Waxed paper
Tuna Fish 320 Prepared Metal
Pineapple 825 Prepared Metal
Crackers 325 Prepared Plastic Silverized
Egglplant Spread 1000 Prepared Plastic
Mineral water 3000 Raw Plastic
Total Food Weight 27305

I’ve often thought about the advantage that athletes and musicians have over software developers: time to practice—lots of it. Most time is spent in exercises and rehearsals, to produce the best peformance.

In software, everyone spends most of the time producing, with a bit of “time off” for learning new technologies. No wonder perfection seems so far off.

A friend pointed out that Dave Thomas has proposed CodeKata as a way of doing that practice. I read it, and while the ideas look good, I felt there was something missing. The “katas” (formal patterns in karate, and here, in design and coding) seemed somehow schoolwork-like and disconnected from real work. I could only imagine myself “practicing” on assignments where I needed the result, even if for something trivial like importing a bunch of e-mails into SharePoint (more about that another time).

I don’t have an answer today, but the question is much bigger than just finding time to practice in software development. So instead, have a look at these posts and presentations where people are discussing the issue, and see what you think.

Level 5 means never having to say you’re sorry (Jeff Atwood)

Big Macs vs. The Naked Chef (Joel Spolsky)

No Best Practices (James Bach)

Herding Racehorses and Racing Sheep (.ppt) (The Pragmatic Programmer)

Competence is a Habit (.ppt) (David Leach)

I was reading Steve Yegge’s rant on Agile, praise of Google, and all the responses there. I won’t get into all that, but one topic that Steve mentioned, as did one of his commenters, Ryan Baker, was “work queues”.

Attraction: (Yegge, in part) “With nothing more than a work queue (a priority queue, of course), you immediately attain most of the supposedly magical benefits of Agile Methodologies.”

Concern: Before writing this post, I thought I should search the term. I found, for example, a utility from The Code Project. Why does that worry me? Because structures that are good for computers are not necessarily good for people. (Unfortunately people who work in computers know those structures best and are often tempted.)

Then I realized that I had had a work queue experience just this past week.

Last Thursday I had 6 Splint warnings in my code. My goal: to get rid of them one by one, and gain some hands-on experience with this open-source static analysis tool. My method: See it as a work queue of 6 items, and attack each one in turn. Well, I tried a half-hour on each two or three of them, and when I was done, I had … 8 Splint warnings.

Why?

From just a quick initial look, I had realized that the warnings were talking about two concepts that I happened not to understand in detail in C just then. (If you’re curious, they are internal/external scope of variables and definition vs. declaration, and how and when to free malloc’d memory — both in the context of structs).

I ignored that realization and started on my work queue anyway. I tried this, and I tried that, and of course failed. Now I will go ask a C programmer who knows. But I could have done that after the first 5 minutes (reading the warnings and understanding them).

What’s the problem?

Work-queue-based work has no direction—no guidance.

It’s good for washing dishes, but not for any activity that takes skill.

For that, get guidance — get a mentor.

Practitioners in other professions may have the problem that the average person doesn’t understand their fields.

We in software development have a different problem. We’re not sure ourselves that we understand our field. How else to explain the fact that we change methods and models every five years, and are fascinated when we realize that something that has worked for years “in the real world” works in software too?

And the reason that we’re not sure? It hinges on the question, “What is software like?”

I’m confident that if software were like something familiar from our growing up, we’d recognize it when we got to it and work much more effectively.

Forgetfulness

For a start, there’s one thing that most people seem to have forgotten. Software was named that because it’s “soft”. It’s not a machine. That’s “hardware”. It’s not a building. That’s concrete — certainly not soft. (By the way, if software is not a building, forget “software construction”.)

Answers that are not

Knowledgeable people will say that software is a procedure to tell hardware what to do. Or in these days of interactive software, to tell hardware how to behave and respond.

But “procedures” are hardly familiar in daily life. Mostly we live and react with little planning, and no procedures. Saying software is a “procedure” is as good as telling me that an “aperea” is a “cavy”. Go look it up.

So what is software like?

How about a kitchen. The layout, appliances, and supplies are the source code. The food you prepare is the object code. And of course the ravenous teenagers at the table are the end users. They change their minds a lot about the requirements. You have to deliver on time and in quantity. And it had better be good too or they’ll just go out for pizza.

Wait a minute though. We generally don’t go re-purposing our kitchens every few weeks. Yes, we might buy a new kitchen gadget here and there, and there are renovations on the traditional 7-year cycle. But it’s still one cook (could be either parent, but usually one of them says, “this is my kitchen”). And the same clientele.

The Cooperative Kitchen

Imagine an unusual, cooperative kitchen. Maybe in some super-modern tourist hostel. It’s got basic appliances and counter space and cabinets. But every week a few different groups come. A family. A company retreat. A summer camp trip. Their cooks all sharing the kitchen, bringing their own pots and pans, recipes, and food supplies.

They cook in shifts: the camp counselors get from 6:30 AM to 7 AM to cook before their hike. Then the family, who wants to get out and see things, gets it from 7 AM for half an hour. Finally, the catering cook comes in to prepare food for the morning corporate meetings. And remember, all these groups will be back for lunch and dinner, so tools and supplies have to be left out somewhere, ready to be used again.

Coding the Kitchen

Now imagine you’re one of the cooks. How would you want the kitchen laid out? Where do you put your knife set; and you, your blender; and you, the catering cook, your cappuccino machine? How do you label your supplies so you can find them when you need them (and nobody else takes them by mistake)? What about clean up? Safety too — don’t store your cleaning fluid in the fridge!

What should such a kitchen look like in order to be easy to work in, and also allow each of you to produce different, varied, good meals for the entire week’s stay?

Epilogue

Well, I didn’t quite succeed. Kitchens are familiar but I’ve never seen a kitchen like this one. If you have, I’d like to hear from you. We might learn how to write better software.