"planning ahead"

Whoa, that's fighting talk. Next we'll be doing big design up front and (god forbid) beginning with the end in mind.

That was tongue-in-cheek, only because everywhere I go these days I see people bowing down at the altar of refactoring, rather than doing a bit of planning and getting it right first time.

Of course - planning is anti-"agile". You're supposed to run around in a constant state of chaos beating on everything with a hammer until a usable product magically pops out.

Refactoring happens when you don't get it right the first time, though, and that tends to happen often even with planning; so it's still a useful and necessary process.

You are correct about emphasizing more planning up front, of course. If anything deserves bowing at an altar, it's designing before you write code.

To be fair, planning ahead and getting it right requires a relatively stable specification of the requirements. This is not often found in a typical business environment.