Feature Driven Development

A short but interesting article:

"Understanding the Psychology of Programming", by Bryan Dollery

Read on for the Abstract and some comments...

"Contrary to popular belief, programmers more frequently resemble artists than scientists. If you want to maximize the creative potential on your development team, you've got to start thinking about the psychology of the programmer and be willing to back it up with management policy."

The article begins with the presumption that programming is in many ways a creative activity. FDD considers devleopment to be a human activity, which is not exactly the same thing, but the principle that development is not a mechanical process is something that we can hopefully all agree on.

I found the discussion of "flow" to be very interesting. I relate this to being "in the zone", where I can code for hours, not notice time going by, and achieve a great deal of functionality by the end. This also seems to be in situations where the design (whether in head or recorded) is pretty close to "the right way". If the design is right, the code just flows, and works. But this is getting into a discussion of implicit vs explicit design (a subject I intend to write up RSN). Anyway, this "flow" is not intrinsically linked to a purely creative output IMHO.

I think one of the most important points is half way through the article, which I would like to summarise as "never ask a programmer where their timesheet is". :)

There have actually been studies done that show the impact of interruptions on productivity. For someone who is in "the zone", a single interruption can cost a good 10 minutes or so. It takes time to perform the context switch, and recover from the interruption, to regain lost momentum. This translates to the idea that 2-3 interruptions per hour can halve productivity. All of a sudden, management has a good reason to look after dev staff.

I experienced this first hand on a project I worked on a few years ago. We were working closely with client reps, and often solicited their feedback on things. But after a while these people started to just wander over to the programmers' desks and start asking directly for their own favourite features to be added, or to request changes, or whatever. Effectively bypassing the change management and design processes. But worse, this barrage of interruptions took a huge toll on developer productivity. Too much interaction is not necessarily a good thing (which would tend to refute one of the points in the Agile Principles).

The solution: we had "Do Not Disturb" signs that we put up in our cubicles. This meant that nobody was allowed to interrupt you while your sign was up. It took some training for management to fall into line, but they eventually did. It worked wonders, and productivity went back up.

So just as FDD concerns itself with managing development flow, in terms of keeping the pipeline full (see Jeff's newsletters for discussion), I think we also need to facilitate individual "flow", and create an environment that is conducive to productive work. Keep your developers happy, and they will produce better results. A relatively small investment now can have a big payoff later on. So it really is a management "thing".

So Jeff, I don't really want a $14,000 shower. But there's this $6,000 hot tub that would be really great...!