Listening to non-technical people trying to manage the inner details of a software project is like listening to a bunch of 6 year-olds planning a trip to the moon.
“My teacher said that its really cold on the moon, so we’d better take our jackets!”
“I’m going to take my umbrella in case it rains!”
“I’m going to take crayons to draw pictures of it.”
“Wait! I read that there’s no air on the moon. How are we going to breath?”
…pause…
“I know! We can take balloons, blow them up, and then breath that air!”
“YEAH! Problems solved!”

It’s OK to involve 6 year-olds in the planning process as long as we don’t let them operate the arc welders, build the spaceship, or fill it with rocket fuel. Likewise, it’s a good thing that we don’t let non-technical folks (or 6 year-olds) drive the technical details of software projects… or do you? May the heavens help you if you’re in that situation!
Assuming that we have “experts” controlling this project, and assuming we have experienced builders choosing our tools and materials, we should welcome this non-technical input with open arms! 6 year-olds are actually the best place to start for user input; who knows better about how to have fun on the moon?!
Amateurs might immediately dismiss the six year-olds suggestions as being silly and ignorant. However, I hope that I could listen more deeply to analyze the six year-olds’ statements, to see through to the underlying concerns, and to find the nuggets of truth that non-technical folks excel at expressing:
(more…)