Whenever I describe the agile practice of pair programming I usually get the same general reaction,which is something like “I don’t think I’d like to do that”. My usual attempt to convince someone that it could be an interesting tool to try is to suggest that verification team could do it for the complicated sections of code, or to have the designer and verification pair program to develop the drivers. While good reasons, these were never enough. This posting will be another attempt on my part to show the value of pair programming, and to provide some suggestions on where programming could be effective for you, and some reasons on why pair programming may not be effective.
Month: September 2011
Sir! Hands On Your Head And Step Away From The RTL!
A handy bit of guidance that I’ve gleaned from books on lean product development comes via the recognition that unfinished work sitting in someone’s in queue, which in lean manufacturing lingo is called inventory, is waste in your development process. Lean software practitioners take things a step further to describe untested and/or unreleased code sitting on a file server as inventory. I reckon doing the same can benefit us in hardware development.
It makes sense to me that built up inventory can be responsible for poor productivity or quality. Why? Think about it… do you do a better job when the amount of work in your queue is manageable or overwhelming? Do you work better when someone shows up at your cube with 10 feature requests or 1? Do you work better under the weight of 25 outstanding bug reports or no bug reports?
I’ll take manageable over overwhelming any day so I can see minimizing the amount of untested and/or unreleased code… I mean inventory… in your development process over time is a good thing. Minimize inventory and you’re minimizing waste. Minimize waste and you’re maximizing productivity and quality.
How about an example that applies to hardware development.