More Development Advice of the Ages
Today we present a rule of team software development that should be obvious on the face of it, backed by in-depth observations from history.
In a previous entry, Development Advice of the Ages, we examined in the light of history the epistemological fallacy of believing that software development is something entirely new and different from humankind's other occupations and undertakings.Translated into plain American, we mean that the same basic rules that apply to farming, statecraft, or managing a restaurant apply to software development. We forget this in our hurry and repent at leisure!
Making and Not Making Decisions
Certainly one of the greatest (in the classic English sense of the word great, that is, large or momentous) decisions of the twentieth century was the decision to use the atomic bomb to end the Second World War. The man who made that decision, U.S. President Harry S Truman, was famed as a model of executive ability. In 1962, Harry Truman described his algorithm for decision making to interviewer Merle Miller, saying that when faced with a decision, he would always ask, "How long do I have?" Then, when informed of the deadline, he would send away the questioner until the deadline, at which point his decision would always be ready.
The lesson I've drawn from this is:
Don't make a decision until you have to, and when you have to, don't hesitate.
Anything you don't decide today doesn't have to be changed tomorrow when you know more. We software types love to build castles in the air and fall asleep dreaming of the crenellated towers of program architecture we plan to erect. Managers love to look decisive: they bang the table and enunciate long chains of directives often without knowing what they are talking about yet.
Specifying early on the basis of our dreams is no match for knocking down the details as we arrive at them armed with hard facts derived from already completed work. Learn to recognize the forks in the road where you must decide. Ponder, research, but don't specifiy until you reach the fork.
Recent history provides what is probably the most striking negative example ever of defying this rule. Without passing any judgement whatsoever on the goals and aspirations associated with the U.S. invasion of Iraq, it is clear that the management of the effort is sibling to the management of many software development efforts:
- Goals were enunciated without associated costs
- Targets and deadlines were established well in advance and set in stone without input from those charged with reaching the targets.
- Management closed its ears to all feedback from those on the front lines.