[fuzzix]

> "I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding."

This I like. The race away from the waterfall straw man has also stripped us of the advantages of BDUF.

While rigid phase-driven project management helps nobody, I think there's still room for speccing as much as we can upfront within iterative processes.

Or you could run to the IDE and start ramming design pattern boilerplate down its throat the second you're out of the first meeting ;)

[hvidgaard]

You should be speccing what you want to achieve: the goals, the why, the impact, the external limitations, measures of success and so forth. This also allows you to describe and plan testing up front. The "how" is best handled in an iterative manner.

A lot of people use AGILE to avoid planning at all, which is a particular destructive anti-pattern, and the exact opposite of what you need.

[fuzzix]

> "A lot of people use AGILE to avoid planning at all"

Yup, I've seen this a lot.

In one instance "Agile" meant I could finish a major task using an unfamiliar language, framework and code base in short order.

Genuinely, the customer was told "Of course, fuzzix here is familiar with Agile processes so you should have this in 3 weeks".

edit of course this also meant there was no formal spec for the task, though I did have a photo of the whiteboard.

[pessimizer]

>The "how" is best handled in an iterative manner.

I think that the first "how" should be planned as much as anything else. I understand how you refactor from v0.0.1 to v5.34.2 iteratively, but I think that getting from vNothing to v0.0.1 is qualitatively different.

If I don't have a complete idea of how my minimally functional thing will work that is small enough that I can completely hold it in my head, and instead just architect by agglutination and test writing, 1) my results are going to be hacky garbage, 2) my first 50 iterations are going to be devoted to replacing it all haphazardly to fix bugs, and 3) the code and interface will become increasingly more complex, harder to work with, and strewn with special cases.

When v0.0.1 is well planned, v2.5.2 may not look anything like the plan anymore, but in my experience it becomes shorter, cleaner, and more correct rather than a giant ball of band-aids propped up with tests.

[hvidgaard]

Personally, once "the goals, the why, the impact, the external limitations" have been defined, we start to do mockups, a programmers "differential", to zero in on a solution that satisfies the demand.

With that on the board/paper/code, we can start to test our assumptions and iterate on the solution. I do not know if that classifies as planning, but it works very well.