In the past couple of days I had an interesting debate with my cube-mate. This all stems from a difference in views about software development.
His take is that if something goes wrong it’s because of lack of care in the design process. If something goes right it’s because it has proper design.
In many ways I take the opposite angle. If something goes wrong most of the time it can be traced to faulty execution. If something goes right, in many ways it’s despite the design.
Ok. I’m being too harsh on design. Partially on purpose.
I take a pragmatic approach to programming — and to most things in life as well. You need enough design an planning to know where you’re aim is right now. This serves to direct your efforts in some direction or other. You can’t just sit an outsider down and say “program me something” and expect to get something useful to your problems at hand.
Design is iterative. You have a problem. You come up with a strawman design. You prototype the parts you’re not sure of. You react and design something better. The process continues until the problem at hand is solved adequately.
The problem with trying to come up with an all-encompassing design is that it takes a long time. Too long. Even then you’ve failed since you don’t know the problems you’ll encounter for real when you’re coding.
In many ways this is like a civil war battle and you’re the general. You know where you are. Your lieutenants are gathered about the night before the battle and they know where their divisions are. You have an idea of the objective: “take the hill” for instance. You think you know where the enemy is. The map is laid out in front of you by the flickering campfire and you talk over the plans with your men.
At that level you come up with plans for the battle. The right side advances, the middle tries to hold the line while the left tries to outflank and cut the supply line. If something is particularly interesting you can dive in deep — how to take out the bridge. If something is normal and ordinary you can wave you hand and gloss over it. The right level of detail for each item in the plan.
You make the plan. No problem.
The plans are made with incomplete knowledge of the problem. You don’t know of the sniper up in the house. Or the ditch that holds an ambush.
The plans serve to start the action. At 0-400 the troops walk out. At 0-500 they need to react to the reality that is in front of them.
The plans are a guide, not the rule.
Poor design and plans can doom you to defeat, but a good — or even great — plans do not guarantee victory either.
The key is flexibility and having smart people around you. The unexpected will happen. It’s your job to react and make the best of the situation.