Exploratory Programming
4 comments
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?)
-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?)
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...
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...
"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.
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.
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?
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?
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?