I think I agree with you in broad strokes — testing and experimentation and exploratory programming are large reasons for increased speed. But it’s important to emphasize that it’s the underlying fluency and ability to make small changes quickly that makes those techniques useful. You can’t be agile if you aren’t small and quick. If that quickness weren’t there, then exploratory programming would have a *huge* time cost, and would not be nearly so useful. With larger time costs comes an increasing tendency to do a BDUF and that leads to decreased speeds, which leads to larger time costs, which leads to a greater tendency to do a BDUF, which leads to.…

Anyhow, it’s exactly the native fluency and willingness to experiment that I need to impart to my students, but I am unclear how to teach it. It seems like a “knack” more than a traditional body of knowledge or a skill, which means that the best I can currently do is repeatedly throw students at problems which benefit from that knack until they start to develop the knack. But that’s basically hazing, and surely there is some less cruel way to go about imparting an exploratory attitude and fluency…

Coding fast is a good thing no doubt, but it’s hardly a be all end all.

I rank the following as far more important:

Thinking clearly about your problem and the abstractions you will use for solving it is the first and foremost task for a software engineer.

Decomposition, which is related to good abstractions, is the ability to find the relevant (independent) sub-problems and solve them (independently).

This ability then goes hand in hand with interface design, and here I do not mean UI design, but API design. Consistent, well-thought through interfaces that are easy to learn, easy to remember, anticipate a client’s needs, and are easily composable, are a key to good software.

Coding is the thing you do at the end when the problem is solved.

That said, you and Pete give a good description of how I prototype. This is almost always understood to be throw away code though, and is not always necessary.

The “fast coding” thing is nice when:
1) I don’t understand the technology I’m working with very well.
2) When there is a tricky algorithmic aspect to what I’m doing.
3) When I’m developing a new technique or idiom.
4) When I’m not exactly sure where I’m going or don’t feel like thinking through a problem. After all it is fun to hack sometimes.

Clearly #1-#3 imply smaller chunks of code, while #4 is basically cowboy coding and probably should be discouraged for “real” projects.

And yes, test-driven code is an asset. It should be obvious that good abstractions, good decomposition, and good interfaces aide the test-driven methodology.