Iteration: A Developer’s Boon
How to use the magic of iteration to turn hack jobs into elegant solutions.
I was reading through my boundless backlog of articles recently while trying to get over some writer’s block, and came back to an article by Dan Mall. In it, he talks about some raw ideas he’d captured in the note-taking app Notational Velocity (of which I’m also a huge user, along with nvALT 2, a fork of Notational Velocity).
The article was basically a long list of ideas he hadn’t fleshed out at the time, and he mentioned how he hoped his list would spark him or others to do some writing. One of Dan’s ideas particularly struck me:
“The Power of 2: Why the second iteration of any deliverable is most useful. First one is a stab in the dark. Third is small revisions. Second is where the magic happens.”
That thought about iteration has just burned into my mind, and I haven’t been able to stop thinking about it over the past few days. Iteration is a powerful tool for businesses and individuals to improve a product or idea, as the small(er) deltas that typically occur between iterations make for less monumental changes that are easier to manage.
Today, I think we take the iterative model a bit too much for granted—most everyone, from small web shops to large enterprise companies, has begun to follow the iterative model and just consider it “good” in and of itself. But since developers can stand so much to gain from using iteration, I think it’s worth reflecting on the affordances that iteration provides.
So let’s take a look at a few ways iteration can make “the magic happen” when it comes to software development.
Continuous improvement and integration
One of our creeds at Rocket Code is meliora, which is Latin for “ever better.” The iterative process has meliora at heart, since with every iteration you are striving to be better than the last: Better animations, better interactions, or a better user flow represent small steps in the ceaseless march toward a higher standard.
As a developer, this typically means writing and improving code in short sprints. This can lead to a more evolutionary process, by allowing changes to come and flow naturally. In many cases when you are using a new tool, workflow or integration, your first iteration will be, at best, that “stab in the dark” Dan talks about—you just really don’t know what you don’t know yet.
(This applies to more than just development, too, of course. That new feature may just be step one for increasing revenue on your product page or converting more users from your content streams—but that’s a topic for another post.)
You can see this kind of evolution in the basic test-driven development (TDD) methodology “Red, Green, Refactor.” In this kind of setup, you first know the test but don’t have the code passing the test (Red); then, you write the code such that it passes the test using the best means you can think of (Green); then, you review the code and clean it up, since you may have not done the most performant or eloquent execution the first time (Refactor).
Why is this important? Sure, that stab in the dark the first time may have worked — but it could also be the equivalent of banging your shin on the coffee table in the dark: You’re just stumbling around. There could be a better way to solve your problem now that you know that it can be solved and have a way to execute it.
There have been many times when Dusty, our creative director, has come up with some awesome interaction that I have no clue how to pull off. So I attempt to execute the creative vision by first just cobbling together a solution that I know will require some refactoring. But why build it knowing that I’m probably going to need to rebuild it?
Because thanks to that first iteration, I know how to approach the solution, and can therefore make a much cleaner product. Having the affordance to refactor your work iteratively can slowly turn a potential hack job into a clean, eloquent solution that seems like magic to your end user.
Reducing the load
Smaller iterations — as opposed to huge, monolithic changes — can also help make things far easier to maintain. This is not to say that you won’t wish you could go back and clean things up sometimes; often, the embarrassment of what you wrote three days ago is drive enough to do better on the next feature or implementation. But after that first push, you have a better idea than when you started about how to tackle that feature or project, or at least clean it up a bit.
This is crucial for a developer, because even though you might be creating bespoke solutions, every project informs the next—just like how every iteration gives you an idea of what to tackle next, and what is and isn’t working for you.
Iterations also help lessen the cognitive load that comes with managing the development process or maintaining a project of any size. You’re able to focus on a concise list of things to do and pieces to change, rather than getting lost in a monolith of code or a hefty list of changes.
What I like to do when starting a project is make a list of items that need to be completed for each feature/page, and then break it down into three categories:
1. basic requirements
2. nice-to-haves
3. if-we-can-get-to-its
While I’m working, I go through and complete all the basic requirements first, then go through the other two categories as I make more passes at that page or feature.
This way, I’m evolving the page little by little as I go, which keeps it from feeling like a monumental task — regardless of the complexity of the page. Along those same lines, smaller changes usually also need only smaller fixes; the number of variables is more controlled, and it’s easier to see how a small piece of functionality might interact with other features.
Iteration as craft
When I was taking a class on interactive design, we had a project that required us to create an alien typeface. One of the important things I got from this exercise was how amazingly connect iteration and craft are. The first version of my typeface was okay, but after the second and third major iterations, it began to really coalesce into something cohesive.
From a developer’s perspective, what this means is that going into building something, the first release won’t be the final, perfect product — and that is completely okay.
Part of our mandate as developers is iterating on what we and others have already done in order to make something newer and better. In doing so, we are able to increase our skill set and efficiency and make better products and features.
“…if you’re not embarrassed when you ship your first version you waited too long.” — Matt Mullenweg, “1.0 Is the Loneliest Number”
I definitely think Matt has it right here: It’s extremely easy to bow to the pressures of “Oh, just one more feature,” especially when the project is near and dear to your heart.
But for a developer, just getting that first launch out the door can feel great, and from there you can start gathering data to see what to work on next. And maybe that sorting function you thought would be a huge deal isn’t getting used as heavily as you anticipated. By taking an iterative approach, you can quickly swap that feature out for something better, or focus your time on a different function that you now see needs some updates.
Iteration isn’t scary, and in the long run, it isn’t really any more work—just a handy way to break big things into smaller, more manageable chunks.
Of course, I’d like to give a big shoutout to Dan Mall for the inspiration for this article. If you liked it, I hope that you’ll follow Thinkship so you can be notified when our next iteration is ready ;)
Want more great content from Rocket Code? Check out Rover, our biweekly newsletter of interplanetary ecommerce insights.
