Sunday, January 10, 2010

Don't be the builder, be the user

I was helping out today with a project my Dad is having done at a business. In the building, there is a need for more workspace and so it needs to be built. I was amazed at the staggering similarity of the conversation between my Dad and the builder and software design conversation. I was on site to be an extra set of hands for construction, meaning my viewpoint was meaningless.

The construction required two free standing walls, and a overhead "rail" to contain electrical down into the units that will be installed against the walls. The specifics of the construction and its are left out intentionally. To conceptualize, the objective is more workspace.

There was no plan, no paper, no agreement. Nothing except conversation, movement of existing workspace to demonstrate possibilities and measurements that resulted in pencil writings on raw material. Once the existing physical objects were in place to demonstrate the projected future space, measurements taken and verbal agreement, the overall planning was done. The builder understood what my Dad wanted, and we were off to buy material and begin construction.

After reading "Doing It Wrong", I was somewhat amazed how such a major change to the environment was made so quickly. A software project would have taken weeks of conversation between technical departments to agree on positioning, material, measurements, etc.

And so I thought, what made this conversation successful? My Dad didn't care about material, measurements, and a majority of the implementation details. The trust existed that the builder would make those decisions himself. My Dad wasn't trying to be the builder.

I think this is a major difference in software / technical planning. Many people seek to be the builder when they have no place wearing those shoes. It's either out of their skill set or job assignment. The perception of technical understanding equaling intelligence is completely out of whack. So many details are exposed unnecessarily, and the conversation to explain those details derails the initial objective so much, that the skillful developer that just knows how to do it, is lost. They are forced down the road of writing specs and explaining themselves to people that don't deserve the explanation. Let alone the boring and uninteresting process of formalizing a design that will entirely change two minutes down the implementation path because one little aspect wasn't considered.

My advice to people who want something out of software is to step beating up the details. The software engineer will figure it out. Don't try to be the builder, be the user. Your product will finish a lot quicker if you push the use over the build.

No comments:

Share on Twitter