Reducing ignorance in development
If you’ve never worked on a development project where in the last week of development you had a moment of enlightenment where you finally figure out what you are building and how it should work then consider yourself lucky. There are too many times in enterprise development where ignorance is the defacto standard and any attempt to reduce your personal ignorance is met with resistance. I have been trying to figure out how to identify where and why it happens on software projects so I could start trying to systematically reduce as much ignorance as possible to help smooth out project timelines and developer effort.
I came across a presentation by Dan North on InfoQ (http://www.infoq.com/presentations/Deliberate-Discovery) that talks about many of the anti-patterns and frustrations that arise from ignorant development and methods that can improve the deliberate edification that moves a project forward instead of letting the team spin their wheels. One of the things that seems to constantly kill progress and momentum is that we don’t know what we don’t know and no one attempts to resolve it. The Dunning Kruger effect (http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) may play a part in creating an environment where ignorance causes overconfidence and if we knew what we didn’t know we might be able to more deliberately and clearly move forward.
One of the slides really struck me because it was so obvious but I was already starting down the opposite path. It lays out the framework for planning from Get Things Done (GTD) and proposes using natural planning instead of the more traditional top-down functional problem decomposition.
The interesting thing here is that it provides a planning and decision framework that can help guide you towards a less ignorant solution. Using this framework we can deliberately move towards a less ignorant view of the world and by iterating over it we can refine an initial idea when we find that things change later. Instead of trying to find all of the problems, solutions, alternatives, and tasks to be done in 1 go we can start with a simple purpose and evolve the concept as we go forward. It’s almost like agile development for ideas and planning.
Like many things communication is important in creating a great team and a great product. If people are too busy talking over each other and everyone is on a different page then you better have a technical wizard who will ignore everyone and get it done anyway or the project will turn out like the projects before it: over time, over budget, and not solving the problem they should have.