"Planning" is highly overrated. The best performers seesaw between "ideas" and "actions."

I like to take this kind of thinking a step further...

Planning to code: good.

Coding in a garage: better

Developing in a living breathing organization: best

No matter how much time I spend on my startup, I always keep an active consulting gig on the side. Routine situations come up every single day that I would have never conjured up in my "ivory tower". The value of fresh ideas and feedback from live users far outweighs the income.

It's also not an either-or choice. Sometimes you can plan to do two weeks of work, then observe, then do it again.

I think it's a mistake to view the spectrum as only having two spots, total planning and completely inductive. Learning how to mix and match is probably a better skill than blindly following either extreme, imo.

It is a one size fits all kind of deal. You just have to try putting it on the right appendage. The difference here is that surgery is a service and software is a product. I think that basically they're the same. You "develop" a service the same way you would develop a product. You practice. In effect, practice is the iterative design of a service, just like rapid prototyping is the iterative design of a product.

Now, the surgeon can't just crack open your head and see what happens, but before he ever does that he's going to have practiced cracking open heads and mucking about with them somewhere (probably on a cadaver). He's probably going to have made some mistakes doing it too, and learned from them the right way to go about cutting up people's brains.

Likewise, you don't just ship the first piece of software you scribble out and see what happens either. Now, certainly with a web 2.0 AJAX calendar-organizer-automated-fish-feeder there's a greater margin for error than brain surgery, but it's a difference in degree, not in kind. If you launch a site that just returns "Internal Server Error" when someone surfs to it, you're going to be about as successful as a brain surgeon who never learned how to handle a scalpel.

So the surgeon cutting up a cadaver seems to me to be the same as a programmer blasting out a broken version 1.0 of his software. They're both trying something out in a situation where they can fix mistakes and reincorporate them to product. The surgeon makes a cut, looks to see if it's in the right place and is the right size, if not he keeps trying until he gets it right. When he can make the right cut every time without thinking about it, his service of cutting people is finished being developed. Likewise, the programmer writes some code, and checks if it produces the right output. If not, he tweaks the code until it does. Same thing. You can't compare a finished version of one product (performing brain surgery) to the development process of another product (writing software).

The problem with planning is that it oversimplifies your lived experience. Very few people live from step to step, they live by their desire, therefore the statement, "the best performers seesaw between "ideas" and "actions" is more of linear effect. You have an idea, you want it to become real, so you try, if some actions to get you to the idea, the key is knowing what actions best produce the idea. An now we are back to planning, which people do more subconsciously than consciously, and let's face it, sometimes you just need to cogitate on an idea for a few months and then it strikes you what to do to make it real. I think the more important question is how do you not loose sight of the ideas you want to make real?

Oh yeah, his won't work for all fields. Iterative development is excellent in software because the cost of construction (ie., running the code) is nearly zero. You can let constant feedback from application guide where you are going.

This is why interviewers like to ask about languages that aren't in the corporate playbook. If someone says "Ruby? Python? Lisp? No, I haven't had the opportunity to use any of those yet," you know you can pass. Not because all good programmers use ruby, python, and lisp, but because all good programmers know that you don't need to "have the opportunity", you just need to install the language and write some code.

It would be unconscionable to learn brain surgery this way, so if someone says "I haven't had the opportunity to operate on a brain yet," that's a reasonable statement.

I actually suspect that writing software is one of the most complicated things a person can do. If we didn't have the advantage of iterative development with cheap compile cycles (or run cycles, if you don't compile), then no system of any real complexity could be built.