Sounds like a truism, right?
But not if you do an iteration 0, as I advocated previously.
“Iteration 0” is often used to build up the development environment, choose an architecture, do planning, and general preparatory work. It’s a good thing, and can save you tons of time later. It’s best summed up in the phrase “getting off to a good start“.
There is one thing more important than getting a good start. That’s getting started. I’ve found myself in paralysis over the hurdles involved in setting up an environment, establishing a process, building infrastructure, etc. And I actually like doing that stuff. It’s my specialty.
I found there was nothing more liberating than scrapping it all– design, testing, version control, integration, environments, processes — and just coding. The instigation was having something to show, a prototype. I actually even got into doing a little UI design, messing with fonts and spacing and things like that (a well known pitfall & tarpit.)
You know what? It got me stoked. It gave me the psychological attachment I needed. There’s nothing like building a little momentum.
I found a bug, pulled out my hair, and did it again when I reintroduced it. If only I’d written an automated regression test to make sure that didn’t happen. I even lost my source once because I didn’t check in and my IDE crashed.
So what? It’s only iteration 1. Explore! Make mistakes! Make big mistakes!! Correct them, start over, do whatever you want. Heck, I had so much fun, and things are rolling so good, I might just move on to iteration 2.
Since we’re dealing with software, having to go back isn’t such a big deal. There are no wasted materials (only time), and it’s not like if you set sail over the horizon without a life raft. You can make changes on the fly, particularly early. Setting up a big framework and process too early can introduce too much rigidity, too much friction.
I guess what I’m advocating, is adding your process, your environment, your QA and all those things iteratively too. Include bits as part of each iteration. For instance: after losing my source, I went back to using version control. Luckily it was already in place, so it was just a matter of choosing to use it. No creating a repository and building an environment to host it.
I could have written a bug and a regression on the first bug, but I’ll let it slide. When the next one bites me, I’ll log into Bugzilla and write it down (luckily, that’s already set up too.) If it’s UI related, I might write some automation exposing it.
When I start to see a need for refactoring (soon), I’ll add some unit tests. Since iteration 1 is almost over, I’m going to document my stories post-facto. That way I’ll know that I’m complete because I’ll detail my acceptance criteria. Maybe for iteration 2 I’ll write them down first.
When I get tired of typing ‘rake test’, I’ll work on continuous integration. I’m only checking in once a day or so now (and there’s only me) so, it’s probably a premature optimization. I just created a test deployment directory that I can manually scp to in mean time.
Check out my progress so far:
With a few more touches, I’ll put a bow on it and call it iteration 1.