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.”

Here’s Ron Porter commenting on that 30-to-1 ratio of productivity we hear about. He talks about the top performers bringing the others up to speed. That’s not a way things work — it’s the only way.

In high school I was always on the “B” team in soccer. (Back then I was a 5 out of 30 at soccer.) My best days were when they mixed us with the “A” team — our defense with their forwards and goalie vs. their defense with our offense and goalie. Playing defense with an “A” team around me made me play better.

There are two reasons to try to make the “A” team; together they offer an opportunity for everyone. Either you are really good so you get on the “A” team, or you want to be good so you need to get on the (bottom of the) “A” team so you’ll improve.

Then Daniel Read asked how Ron mentored welders. (That’s what Ron was doing before he was programming, and perhaps before he started building boats.) Ron gave a 3-step program:

1. Stand up to superiors
2. Be willing to suffer ridicule
3. Keep records of everything

That’s my paraphrase — read how he said it: How to mentor a welder.

Ron, you’ve got it exactly right. I can assure you that it is “directly transferable to … other kinds of jobs.” Certainly not just programming. I sometimes think that programming (now called “software development”) is the only profession that thinks it’s so, so different. Yes software is different, but people in it are not.

About whether mentoring works like this everywhere: of course it does. It’s simply called “how people learn”. I wrote about it here. But don’t read me. Read Ivan Illich’s Deschooling Society.

When I’m not reading or working, I’m learning to roller blade. A pair of skates, a video here, a website there, and some practice. Gets me to about 1 out of 30. Apply Ron’s rule #2 though, and I go out to the park where all those kids skate circles around me. They’re all 10-out-of-30 going on 20-out-of-30 skill-wise. I watch them and even ask them questions. They’re fascinated for a moment that an adult might ask a kid how to do something. But they get over it quickly — acting like natural mentors. Which they are. And how about that — now I can actually skate around the neighborhood.

Mentoring is no mystery. It is kids’ stuff.

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.

A co-worker passed me a copy of Joel Spolsky's blog posting Human Task Switches Considered Harmful.

There are a lot of people these days saying that multitasking is inefficient for software developers, but Spolsky has made it really clear with pictures and numbers.

What's striking about his example is that he shows how even a computer, given common software project constraints (two equally difficult tasks that both must be completed), will produce results sooner, on average, with sequential tasking.

That's a bit of a surprise to our intuition, since multitasking was invented for computers, wasn't it?

What was multitasking designed for?

While not the earliest computing example, the one most familiar to end-users is multiple windowed applications.

In CPU terms, as in Spolsky's article, that means multiple tasks where most are expected to be idle.

Why are most Windows application tasks idle? Because the user is single-tasking. S/he can only work on one application, such as word processing, or spreadsheets, or e-mail, at a time. Multitasking is a good strategy for the computer since it needs to prepare several applications to run, and be ready to put up the right one at a moment's notice.

Coming back to people, it's often pointed out that multitasking is an essential ability for managers. And sometimes those managers wonder, "If I can do it, why shouldn't developers?"

When is multitasking appropriate?

My wife keeps reminding me that once I'm at home with the family, multitasking is where it's at. I admit I don't adjust too well. But how else to attend to kids' requests, ever-ringing phones, and visitors at the door, while trying to enjoy dinner together?

The work of running a home is supportive and ongoing. Not long tasks to finish. Nothing gets finished. Rather, lots of existing activities have to be pushed along, and preparations have to be made for upcoming activities (e.g. phone the friend's parents to arrange that sleepover next week).

Managers also push many activities forward, never get to finish anything, and are always looking ahead to prepare the next activity. Management, as modern literature reminds us, is a supporting role. This is the kind of job that requires multitasking.

(Lest anyone think that's devaluing managers or parents, remember that the other part of those jobs is leadership. More about that another time.)

In summary, multitask where appropriate: multiple ongoing activities where none finish and many must be idle.

That does not sound like the job of a software developer.