Resilience is better than anticipation

I read this article from Trizle, which reminded me of this.

I Googled "resilience vs anticipation."

I found an article by Chip Morningstar, which I thought would appeal to GTD/planning/organizational freaks like us. Here's a (long) quote:

My new religion, in the realms of project planning in general and software development in particular, is what I guess I'd call "hyperaggressive incrementalism":

Do really small steps, as small as you can manage, and do a lot of them really, really fast.

Don't do anything you don't have to do, and don't do anything that you don't have an immediate need for. In particular, don't invest a lot of time and effort trying to preserve compatibility with things that don't exist yet.

Don't try too hard to anticipate your detailed long term needs because you'll almost certainly anticipate wrong anyway. But be prepared to react quickly to customer demands and other changes in the environment.

And since one of the dangers of taking an incremental approach is that you can easily drift off course before you notice, be prepared to make sweeping course corrections quickly, to refactor everything on a dime. This means that you need to implement things in a way that facilitates changing things without breaking them.

Don't fix warts in the next rev, fix them now, especially all the annoying little problems that you always keep meaning to get around to but which never seem to make it to the top of your todo list. Those annoying little warts are like barnacles on a ship: individually they are too small to matter, but in aggregate their drag makes it very hard to steer and costs you a fortune in fuel.

Simple is better than complicated. General is better than specialized. But simple and specialized now is better than general and complicated some day.

With respect to software in particular, adopt development tools and processes that help you be resilient, like memory safe, strongly typed, garbage collected programming languages and simple, straight-ahead application frameworks (i.e., Java very good, J2EE very bad). I also favor rigorous engineering standards, ferociously enforced by obsessive compulsive code nazis. I sometimes consider it a minor character flaw that I'm not temperamentally suited to being a whip-cracking hardass. Every team should have one.

Writing things down is good, but big complicated specifications are of a piece with big utopian plans: too ponderous to be useful, usually wrong, and rapidly obsolescent.

In general, it is better to have a clear, simple statement of the goal and a good internal compass, than to have a big, thick document that nobody ever looks at. That good internal compass is key; it's what distinguishes a top tier executive or developer from the second and third stringers. Unfortunately, the only way I've found to tell whether someone is good in this respect is to work with them for several months; that's pretty expensive.

My bias at this point is to favor productivity over predictability. It's OK to have a big goal, possibly even a really big, visionary, utopian goal, as long as it's just a marker on the horizon that you set your compass by. Regardless of what plans you may have (or not), a productive process will reach the goal sooner. Though predictability is elusive, productivity, in contrast, is actually achievable.