Archive for June 2006
Not Like Anything You’ve Ever Seen
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.
Struggling to Learn Together
For better or worse, the educational model of the school, particularly of the university, serves as the basis for training and learning programs in the workplace. It is also the model familiar to many new workers, since they have recently come from that same school environment.
One of the burdens schools face is deciding when to attribute work to a given student, in order to use that work to give student a grade. They deal with this challenge through codes of academic integrity.
How do these codes prepare students for, or hinder workers in, exercising a crucial success behavior in the workplace: cooperative learning?
To find out, I searched Google with the phrase “working together academic integrity“.
There were some positive guidelines here and there such as:
- It’s fine for the group to discuss problem sets, class topics, and so forth. It’s fine to ask others to explain methods and solutions you don’t understand. Together, you can go over the problems several times until you understand. (From University of Windsor.)
But the results also included restrictions such as:
- You may not give or receive help on the programming assignments, except from the TA or the instructor.
- You may not show your program to anyone else until after it has been graded.
- Unless working together on an assignment has been specifically approved, it is not allowed.
Clearly, universities are struggling to say the right things on these issues, and do not speak with a single voice.
But what’s really so hard about the issue?
Time out for some skiing
I’ve only skied once or twice in my life, so each time I was back on the beginners’ slope, taking lessons. Imagine this set of rules posted on a snow-covered wooden sign next to the practice area:
|
Integrity on the Slopes In order to ensure that each student is graded correctly and fairly in their skiing lessons, the following rules must be observed:
|
Who would pay for ski instruction under these conditions? Who would learn to ski?
A Simpler Idea
Back to academics, or rather, training in the hi-tech workplace, why not just say:
- Cooperative learning is essential: work with others
- All sources may be used; if not yours, credit the author
Is there anything more?
Models of Work and Learning
Code review has been shown to be 10 times more cost-effective than dynamic testing in finding defects and suggesting fixes. The reason: economies of timeliness — catch the problems earlier and they’re much easier to analyze and fix.
But still, when confronted with defects, what is your reaction: need to fix or need to learn?
If “need to fix” then choose Fagan Inspection for code reviews.
If “need to learn” then choose training.
If both, then choose mentoring and professional reviews.
On a related note, is learning separate from work?
If yes, then establish a good training program.
If no, then establish a good quality mentoring program.
Finally, in a company, who needs to learn?
If you believe that each individual needs to learn, then restrict information about individuals’ skill sets to individuals and their managers.
If you believe that teams need to learn, then make information about individuals’ skill sets available to everyone.
Whatever you do, think about the questions and your responses.
Make sure you choose the path that follows logically from your responses.
Sharing Reflective Learning
Chrishmorris talks about Reflective Practice and suggests keeping a diary of reflections on one’s work. Even better, perhaps, than writing it down in diary would be talking with others about it, while it’s still fresh in one’s mind.
I work in a multi-lingual environment though everyone understands and speaks English quite well. But worse than speaking different languages is speaking the same words while meaning totally different things.
This challenge is hardly limited to software development.
The problem, though, is that in communication-focused fields such as, say, peacemaking or family counseling, at least people realize that communication might not be happening.
In software development, and in the modern office in general, everyone thinks communication is happening when in fact it isn’t.
The beginning of a solution is regularly starting serious conversations with the goal of explaining (reflecting on) our own experience of a particular activity, and with the assumption that we probably start out using the same language to mean very different things.
When you are convinced, through feedback in such conversations, that the other person has understood you, and vice-versa, then some real learning has occurred.
On Time Delivery
When a major express mail company promises “on time delivery” I think we all know what they mean. In software, I’m not so sure.
In a previous post I talked about multitasking: when it’s appropriate and why. One of my key assumptions was that software deliverables result from tasks that are finished — completed. If so, then multitasking was not good for developers.
But let’s check that assumption. Maybe the software market is a market where
Partial results matter, and
Any late result is worthless
For example, if you’re running for a plane and lose a shoe. Better to make the plane and buy new shoes at the other end, right?
Some questions arise, though:
How partial can the initial result be and still matter?
Partial in features or partial in quality?
Is a later corrective delivery a separate, on-time delivery, or a completion of the initial delivery, thereby making it late?
How much fun is it to always be running half-barefoot for a plane?
What I do know is that when my express mail package comes damaged, missing items, or late, I demand my money back. If it happens twice, I switch carriers.
P.S. What happens when the client you were going to visit by plane is on the plane, sitting next to you?
Putting Multitasking In Its Place
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.
Making Software Better
Everyone wants better software. And for decades, everyone has put forth ideas on how to make it happen.
Sometimes a good way to sharpen thinking on a subject is to take a brief time-out and consider a parallel field.
I can’t help but choose a field where the state of the art, and the state of the practice, are also sufficient to have changed our lives, but still fall far short on safety and security.
Consider driving.
Process vs. Practice
The road is the process. Roads are important. I wouldn’t drive without them. But nobody would claim that driving is happening without cars.
Driving cars is the practice.
Further, cars still don’t drive themselves. People drive cars.
Training
Process training is studying the traffic laws and signs booklet and taking the written test.
Practice training is going out with a driving instructor and driving with his/her guidance.
Certification
Examinations: Ok for the process. Insufficient and misleading for the practice.
Passing the driving test neither makes people better drivers nor proves that they are sufficiently good drivers.
Insufficient: All it manages to show is that under certain heroic conditions, the driver can perform — one time — passably well.
Misleading: Gives everyone the idea that passing the driving test is the “clean bill of health” for all future driving by that driver.
Review
Peer Review
Driving on the same roads with other drivers does not improve any given driver’s skills, nor the average skill. Generally it reduces the average towards the lowest value.
Pair Programming
Sharing the driving with a friend on a trip does not improve either driver’s skills either. At best, prevents accidents, by sharing the driving hours or buying the friend coffee.
Trends in Driving Performance Improvement
(Try to categorize as process or practice improvement. Or as exit-testing, exams, or coaching. Or proactive, preventive, or corrective.)
– Restricting youth driving to daylight hours
– Raising the driving age
– Raising the drinking age
– Requiring youth to take 28 or more driving lessons
– Lowering the maximum speed limit
– Speed cameras
– Higher fines
– Improving the roads
– Improving the cars (ABS, airbags, rearview mirrors on both sides, upper rear stop light)
– Requiring all new immigrants to take a refresher course
– Requiring all new immigrants to take 1 or 2 lessons and a driving test
– Requiring youth to drive with parents (or is that requiring the parent to drive with youth?) for the first N months (where trend is increasing N)
– Advertising campaigns promoting that it’s desirable to give the car keys to someone else and take a taxi home if s/he drank too much
– Other trends I didn’t think of …
Which are best? Why?
Software
Back to software development. Seeking better software, better ways to develop software. And ever-improving developers too.
Software Improvement
What are the analogous improvement ideas? Which would be most effective? Why?
Talk About Quality 