Thursday, January 14, 2010

Classic Mistakes

This blog post, Classic Mistakes Enumerated, from Steve McConnell's book Rapid Development, provides some great ideas (by inversion) of how to increase productivity.

Interestingly, while I began this project assuming I'd discover research about the speed of different software development methodologies, a lot of it seems to be returning to psychology in general, and motivation in particular.

The first mistake mentioned (though they're not in any order) is undermined motivation:
Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor (Boehm 1981). In Case Study 3-1, management took steps that undermined morale throughout the project--from giving a hokey pep talk at the beginning to requiring overtime in the middle and going on a long vacation while the team worked through the holidays to providing bonuses that work out to less than a dollar per overtime hour at the end.
It seems that motivation will be a big part of this year's endeavor.

"Noisy, crowded offices" is another interesting one that we may be falling victim to.  As an ever-growing start-up, we just had to redesign our tech area to accommodate more cubicles.  I'm hoping my offer of free noise-cancelling headsets to anyone who wants them will ease the pain a bit, but I'll have to make sure we don't start feeling like a zoo.

And "shortchanged quality assurance" hits particularly close to home right now.  Given last year's focus on quality, we've had a pretty good streak of high-quality releases.  I thought we might ease up on QA a bit in the name of getting code out the door more quickly.  We half-tested that hypothesis recently by picking a project that could "probably skip QA", given its apparent simplicity and the small risk involved if something went wrong.

In the end, we did some quick QA on the project -- and, sure enough, turned up enough bugs that it made us grateful for not skipping the process.  Had we avoided QA, all the same issues would have had to be addressed -- except we'd have to drop everything to fix them immediately (since they'd be on production) instead of being able to fit the fixes into our overall workflow.

No comments:

Post a Comment