Andy Brett

The sun began to set over the mountains, which had been turned light green by the slowly advancing line of new spring leaves that had nearly reached its peak of the tree line. The second of two days of deck deconstruction and reconstruction was coming to an end, and looking around, I was secretly disappointed at how little visible progress we’d made.

At some point during those two days I’d had a flash of insight, the kind of moment when you can practically feel the synapse firing in your brain. This is just like a software engineering project. And not just because we got less done than we intended, either. The more I thought about what we had undertaken and accomplished, the more parallels I saw.

The project as a whole was a deck deconstruction (several supports and pieces of the deck itself were old and rotting) followed by a reconstruction. It may help to put a microscope on one specific example here. Since several supports had been replaced and had slightly different dimensions than the old ones, some of the deckboards were no longer completely snug with these supports. Definitely not a structural issue, but a minor aesthetic one; also, the boards themselves were certainly aging as well, but it wasn’t completely necessary to replace them. In other words, a tossup on whether or not to rip them out and replace them with new boards.

The owner of the deck, an elderly but still strapping gentleman who was also the foreman of this two-man work team, decided that there was reason enough to install new boards. Prior to making that decision, he probably did a quick cost-benefit in his head - how much better will it look with new boards? What about the fact that the new boards won’t match with the old ones? How long will it take to rip up the old boards and put in the new ones? Are there any requirements from the client (his wife) about what the deck should look like or how long it should take? What are the penalties associated with not meeting those requirements?

Further similarities emerged after I started to take the board out. The nails used to hold the boards in were very old and tough to remove; it was therefore taking much longer to finish the first part than anticipated. Do you continue on the current path? Maybe even reassess the situation and make another decision with the new information?

At another point we realized that the ideal tools/supplies we needed were in town, a 30 minute drive. Another decision - do we use a “workaround” (very common term on a software project)? Sacrifice the time to get the supplies? How does that impact the amount of daylight we have to work with, and is there anything else we could pick up from town while we are there to make it more appealing to go?

I also realized (again) that I tend to think in very general terms about things - this is part of the reason I make these far-flung connections in the first place when other people think I’m off my rocker. A “project” is therefore anything that one or more people put their time into (ideally with some sort of plan for it), a “client” is anyone that anyone has to answer to, “requirements” are the things that constrain the design and give the project a shape and direction. People that work as consultants have similar mindsets - which may be why very little “actual” vocabulary is required outside of technical vocab. But in some sense, everyone is a consultant, since everyone works with resources, such as their own time, skills, and wealth, in order to create something for a client. In the ultimate meta-thought: the term “consultant” itself has become vague to the point of meaninglessness.

Profound thought of the day: The nuances no longer come in the words we use to describe the world, but rather from our experiences as we interact with that world.

[Update: Discovered a related post and discussion over at the 37 signals blog recently.]