Code Vigorous


navigation
home
github
mozillians
email
about
Dustin J. Mitchell

Software Development as Surfing

19 Dec 2020

I grew up on the coast of Maine, where when the ocean temp hits a balmy 55°F (13°C, 286°K) everyone heads to the beach for a swim. I spent a lot of my youth “bodysurfing” in the relatively small summer curlers that crashed on the nearby beach. If you’ve been surfing, you know there’s a “sweet spot” in a wave where it does all the work for you, and it’s a thrill when you find it. Get too far behind the wave, and you’ll fall out of it and wait for the next one. Get too far ahead and the downward flow will dunk you and you’ll pop up behind the wave again.

Thinking back over the software I’ve been involved with, I think there’s a parallel story.

Sometimes software development feels like a drag; like we’re struggling to keep up or even falling behind. Maybe that’s too many great ideas and not enough people to implement them. Or maybe implementing those ideas is just so time-consuming that it’s not worth the effort. On a project with a lot of users, a losing battle with bug reports might be behind this feeling of endless struggle.

At the other end of the scale, a project can feel like summer vacation: plenty of time to work on whatever catches your fancy. Add some snazzy formatting? Sure! Refactor to use that cool new library? Don’t mind if I do! Rewrite it in Rust? Why the heck not? But at some point, reality catches up: in a business product, it turns out customers don’t pay for refactors. In an open-source project, bug reports and feature requests start to pile up, while contributors struggle with merge conflicts and navigating scores of half-finished rewrites. There’s a brief period of panic, and the project finds itself struggling to keep up once again.

The most productive times, when things feel fresh and exciting, are somewhere in between. Each bit of work accomplishes something, and sets the stage for a next step. And that next step leads to another next step, each step improving the application for its users. When a project is in this “surfing” state, it almost gamifies development: “just one more pull request and I’ll finish for the day.” And when that PR is merged, it’s just a few dozen more lines and you’ve knocked out yet another feature request.

For open-source projects, this state is great for growing the contributor community: there’s a rapid stream of impactful tasks, ready for newcomers to pick up. And when those newcomers finish that task, then they have all the context they need for the next task, and before they know it they’re a regular contributor.

I hope this metaphor can help others to recognize the state of software projects they interact with. And for those that lead projects, hopefully the ideas here help find that sweet spot of effective, rapid, self-sustaining development.