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 like the lightweight development processes like scrum or XP with their philosophy of “you’re not going to need it”.
Anonymoussays:
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.
Cyrilsays:
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.
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?