

Exploratory Programming - ptn

I've been thinking a lot about exploratory programming, but I don't
really understand it; I don't get this "you don't really know what you
are writing until you write it" thing.<p>pg says in the programming FAQ section of his site that you should use
exploratory programming when the problem is complex and ill-defined, but what counts as that?  Every time I've sat down to write code I've had a general idea of what the main purpose of my program is and no idea at all about design details (how I'm actually going to implement my vague ideas) or extra features (which are dictated by the users).  Is that exploratory programming?<p>Also, what can you learn from a first prototype?  If the idea is to get
a minimal version of your program running and expand from there one step at a time, then it seems that what you are really doing is writing the chore of something and then let the users dictate how it should expand.  Is that what you expect to learn from a first draft?
======
slackerIII
There are several things you can learn from a simple, initial version:

-how users actually use your product. The best way to do this is to actually watch them go through your product (either through logging or through usability tests). The things you think are important right not might not be important to the average user.

-where your scalability bottlenecks are. I'm not talking about the obvious ones, I'm talking about ones you can't predict because the real world is hitting you with 100x more traffic than you can simulate.

-better architecture in general. Let's say you have an app that is transferring stuff over the network. You have to manage your buffers, deal with encryption, compression, disk IO, stuff like that. If you are dealing with multiple problems you haven't tackled before, you may not come up with the simplest, easiest to maintain design. But, once you've solved the blocking problems (how do I use these new libraries?), you are better prepared to handle higher level problems (Is there a simpler buffer design that lets me reduce the number of copies I do?)

------
jonnytran
I don't know if you're a writer, but it's the exact same thing as when you're
writing an essay or blog post.

You have an idea, you start writing about it, and then as you write, more
ideas that you hadn't originally thought of start flowing, and you write them
down as they come. So in that sense, you don't know what you're going to write
until you actually write it. The act of writing one thing triggers new
thoughts and ideas, which you immediately write down, which triggers more
ideas.

To me, that's the only fun kind of writing. It's the kind of writing I do to
analyze or explain something to myself. The kind where I'm breaking new
ground. Thus, exploring.

P.S. I think this is a perfect opportunity to inject a link to a blog post of
mine "Programming Is Writing"
[http://plpatterns.blogspot.com/2007/09/programming-is-
writin...](http://plpatterns.blogspot.com/2007/09/programming-is-writing.html)

------
bdfh42
"Exploratory programming" is not a defined methodology but an approach to a
task that has yet to be fully defined.

You explore the possible by writing code blocks and combining them in
different ways - looking at alternate algorithms and outputs. Eventually, the
overall program objectives will start to become concrete and the architecture
will exist - even if just in outline.

------
vanekl
some of the coolest problems are the problems that don't have a polynomial
solution, so clever heuristics have to be discovered that work in most
scenarios and compliment your data and requirements. for example, trying to
solve a problem when there are not enough cpu cycles to even traverse a
fraction of the total search domain. instead of looking for the perfect
solution, you search for a solution that is good enough. which leads to the
next question: how do you know when you've got a good enough solution?

