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.