Tuesday of last week I spent much of my day painting walls for a house that our local Habitat for Humanity chapter. It was a lot different than my usual work and it gave me time to think about the parallels between working on the house and shipping software.

First, you could see your progress and your team’s progress building a house just as you can see your progress creating a software program. While I was painting, others were doing other finishing work like installing trim. When I entered the house to start painting, I went up some temporary stairs in the front and when I had to leave, the front porch was about half-way done. That visual progress is great for morale and important to let everyone see that things are happening.

Another similarity is the jobs we did. Chris Peters made a point during the Word for Windows 6.0 project that we should not see ourselves as developers who write code, testers who test code and program managers who work on specifications. Instead each day we should think about what we could do to help ship a great product. Now obviously as a developer that often means writing code or debugging existing code, but sometimes that means sitting down with testers and helping them map out their test plan. Sometimes that means sitting down with documentation writers and explaining how the product works. And sometimes it means suggesting that a feature get cut or scaled back because it won’t be ready on time (which would lead to removing code). All of those things help a project along towards it’s ultimate goal - getting into users’ hands so they can enjoy your hard work.

A similar thing happened at the Habitat worksite. Each of us had some skills that we brought to the project, but those skills weren’t necessarily the ones needed most. So we did tasks that helped move the “project” along and got it closer to “shipping.” If we insisted on doing what we felt was our “job” we might have extra wood where it doesn’t go and not enough of the walls painted.