Archive for October 2006
Standards compliance is the unsung hero of modern product usability. It’s how every appliance plugs into any outlet in your house. How gas from any gas station works in your car. There are even standards for the size of the spout so that you don’t put diesel in your gasoline-powered car.
So it comes as no surprise that where that most popular consumer appliance, the car, meets the most modern one, the computer, someone has made a big effort to define a standard. Specifically, the (British) Motor Industry Software Reliability Association has set as its mission, “To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.”
But what does that mean to the individual software developer?
Your company buys the standard (it’s becoming popular with many embedded software manufacturers, well beyond the car industry). Developers read it. Maybe there are a few lectures on the benefits and the details. But is that enough?
Fast-forward to a typical work day …
Developer is in the middle of coding for an urgent delivery or bug-fix, and is confronted with a compiler warning, Lint-type warning, item in a coding standard, or code review comment. (If the company has done its deployment job well, all of these different types of warnings will ultimately be connected to the coding standard.)
What’s really going on for the developer
The developer has to understand the warning, standards item, or comment, and then decide:
- How to change the code to comply, while not breaking anything else
- When to make the change, in order to meet the deadline for the rest of the features/fixes in the delivery
The coding standard is no help for either of these decisions.
Both decisions are context-sensitive, and require guidance (or mentoring — call it what you want) to decide correctly.
For the producer, standards compliance includes a learning effort. And in software development, that learning effort can be significant and ongoing. The learning program must not only provide the understanding, but also the people to accompany developers as they confront these two decisions over and over.
The first step is participants’ acknowledging this reality. Second is identifying the mentors and allocating their time to read code and provide guidance. Then you can plan a learning program for code quality improvement through standards compliance— a program that works.
8-year-old, to friend: You don’t know how to spell!
Friend: Oh yes I do!
First 8-year old: The opposite of “enemy”—spell it!
Friend: That’s easy: f-r-i-e-n-d.
First 8-year old: Nope!
Friend: Huh? OK smarty, how do you spell it?
First 8-year old: i-t.
How often are you in a meeting, or a hallway conversation, where everyone jumps right in arguing about who’s doing it, or how to do it right, or how to measure it? If you catch yourself for a moment, and take a step back, you see that everyone is talking about something different. Even if there’s a conclusion or a decision, it didn’t really follow from the discussion.
Taking just one example, let’s talk about code review.
Part of being respectful when deploying code review, as with any process, is first checking if anyone is doing it already, and learning those examples. I spend some part of my time these days looking for those people. Every so often I find someone who says, “Code review? Sure we’re doing it.”
But then I start asking questions. I admit I have an opinion in mind. Some minimal attributes of code review. But listening means asking my question and then keeping quiet, so I do.
I ask, are the issues recorded? (Yes? Can I see them? No? Why not?)
Do you review all the code? (No? Why not?)
What does the code author do with the issues? (How do you know?)
When you do these code reviews, what is your goal? (Why? And are you meeting the goal?)
How often are these code reviews? (Haven’t done any in a while? When did it stop? Why?)
I consider myself fortunate when I actually get answers. I haven’t had any positive, consistent answers yet.
Does that matter?
Well, without these answers, I know nothing about it.
So, code review—are you doing it?
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.
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.