Here is a simple recipe I have learned for efficient software design:
Less planning, more prototyping!
Planning is typically a long and expensive process. Some “experts” justify it by claiming that one week of planning saves ten weeks of programming. In practice, this payoff rarely comes. Why? Because as you make progress, the project itself changes and the planning becomes obsolete.
I am not saying you should not manage and plan your projects. However, all planning should be short-term. The only question you must answer is:
What is the most efficient use of my time today?
In short, I advocate you follow a greedy algorithm to manage your time and your projects. Given that your problems are ill-defined and constantly changing, maximizing your short-time efficiency is the only sane thing to do.
Stop investing your time today in the hope that you will be efficiency tomorrow. Be efficient now!
Of course, if you live in some huge slow-moving corporation and work on problems that will remain the same for decades, then please do plan ahead!
Update: What if you are asked to provide engineering-like schedules and deadline? Make them up.
Are you familiar with the scrum development process? It achieves a nice balance between the risks of over- and under-planning.
The biggest risk of under-planning is that you waste a lot of time solving the wrong problems, rapidly going nowhere. Granted, you make a good case for the converse risk, which is that you over-plan for a future that never arrives.
Perhaps you gave your “huge slow-moving corporation†as a straw man, but let me caricature the other way: if you have no idea what you might need more than 2 days in advance, then the greedy algorithm is optimal!
+1 @Daniel
I like the lightweight development processes like scrum or XP with their philosophy of “you’re not going to need it”.
Are you familiar with the scrum development process? It achieves a nice balance between the risks of over- and under-planning.
The biggest risk of under-planning is that you waste a lot of time solving the wrong problems, rapidly going nowhere. Granted, you make a good case for the converse risk, which is that you over-plan for a future that never arrives.
Perhaps you gave your “huge slow-moving corporation” as a straw man, but let me caricature the other way: if you have no idea what you might need more than 2 days in advance, then the greedy algorithm is optimal!
I’m not a programmer but a learning designer and I apply the same philosophy. For me planning must be minimal. I’d rather make a good analysis of the situation and lay out some basic guidelines based on that analysis rather than trying to plan every details before starting to develop. What matters to me is more the result than the process.
In my mind, the more you plan the more things are likely not to happen as planned. Building prototypes is an excellent way to find out what works and what doesn’t and it allows for the client to provide input on some actual material rather than on some vague concept laid on paper. Improving the prototype is often faster than having to rework a plan since most of the time we only know the plan failed once we started developing meaning that we must not only rework the plan but redo, at least in part, what has been developed so far.
I suspect there is no silver bullet in the matter though, and the choice of planning vs. prototyping may be highly dependent on the individual.
Some people (like yourself apparently) are very efficient at moving through prototyping.
I greatly admire that but I personally am completely unable to follow the same path. I have to spend sometimes unreasonable amounts of time in some form of planning.
This does not mean that plans do not change during the programming phase though — they always do.
Another way of saying the same thing is that we all try to maximise efficiency, but I suspect there is no universal optimum. One person’s optimum may conceivably be different from somebody else’s.
PS: Is the spam protector a bit touchy today?