Ingredients
I have a tendency to want to write a program first and design it later. Given that my academic background is not computer science, I often feel that I'm missing something about spec writing, design, etc. And I am. I believe that the penultimate of hubris, a path I traverse more often than I would care to admit, is to make any emphatic statement about a thing for which one has little or no first-hand knowledge.
Recently, one of my fellow developers gave a presentation on UML and highlighted the differences between forward and reverse modeling. Reverse modeling builds an abstract representation from an existing implementation. Forward modeling is the opposite. Build the model first, write the code second. Both are valid approaches to modeling.
Last Tuesday I attended the Agile Austin meeting with Ben. One thing which really resonated was the speaker's assertion that you need to shape a work flow to suit your process. As with any evolutionary system, there must be room to specialize.
In film, there is a certain time of day, around the sun's rising and setting, when the natural lighting is ideal, which is referred to as the “magic hour”. On a shoot, entire days and weeks of preparation may be all centered on getting a few seconds in the can during this small window.
Last week I read this blog entry by Joel Sposky. In this entry he writes (and I'm pulling this quote out of context, so I highly recommend that you read the entry, though for the sake of brevity, I will summarize the context as: a statement on the relationship between a software spec and the resulting program):
“...the bottom line is that if there really were a mechanical way to prove things about the correctness of a program, all you'd be able to prove is whether that program is identical to some other program that must contain the same amount of entropy as the first program, otherwise some of the behaviors are going to be undefined, and thus unproven. So now the spec writing is just as hard as writing a program, and all you've done is moved one problem from over here to over there, and accomplished nothing whatsoever.”
Soup:
So my tendency to want to build first, design later, may not be entirely misguided. It seems to me that the real trap here is the “which is better” conundrum. Both may be valid. This soup is about the way I prefer to program, which may be summarized in the following order:
Spend a little bit of time thinking about what I want to write. If someone else is coming up with the idea, spend a little bit of time brainstorming with them. DON'T WRITE ANYTHING DOWN YET.
Implement the brainstorm immediately. Within a few days, or a week.
Analyze the result (document and model; often this ends up in a readme) and recurse.
Some things to note about this process. First, the post-brainstorm implementation implies a manageable chunk. It's not to say that you can't build large apps. But build incomplete representations of the large app first.
For instance, if you're going to write a classic MVC app and each aspect will probably require several weeks to implement, then the first offering might be a simple glue code program which interacts with stubs that print statements about the “real” code that should ultimately exist there. That is, if a controller needs to do a series of complex database operations, then in the initial version, the controller will print a message like, “doing complex database operations…”.
The point is, nothing should derail the programming “magic hour” which follows a good brainstorming session. Things can be re-factored and analyzed later. In the beginning, generate velocity. Ultimately the resulting inertia can be much more easily molded into the desired result. But as with bicycles and sailboats, it is very hard to steer a thing which has no motion, or in programming, doesn't do anything.
Cleanup:
This, by the way, IMO is the primary reason for the ubiquity of Hello World.
Obviously, this article is mostly out-loud thinking about my own process. It's unoriginal, plagiarist, and derivative. It's specialization.