Posted On: 2024-08-05
When rapidly iterating on new ideas, developers often eschew abstraction and planning in favor of "quick and dirty" code - that is, writing code that gets results immediately, regardless of design/maintainability issues. In many cases, that is warranted: good design is an investment, so saving on that cost means less waste when the code is thrown away. Sometimes, however, slowing down to do a bit of design can speed up iteration, making it less wasteful overall than sticking to the "quick and dirty" approach for every task.
I recently had a design idea, and I wanted to test out whether or not it was fun before committing to using it for anything. Testing out the idea required building a (highly simplistic) graph, as well as supporting a user being able to select/deselect individual nodes in the graph. As I'd no intention to use the code for anything else, I tried to implement everything with a "quick and dirty" approach, but I ran into an issue that forced me to slow down and really think through the design of the selection system.
This design session revealed that what I'd thought was a single coherent set of rules for selection was actually an amalgam of two (mutually-exclusive) sets of rules. In unpacking these two sets of rules, I realized that they shared a set of common affordances (which nodes are eligible for selection, how many nodes can be selected at once, etc.), and I could easily come up with many different ways of implementing those affordances. If I'd continued using a "quick and dirty" approach, I would only need to code one set of rules (and revise it as needed). With only a tiny bit more effort, however, I could turn those affordances into an interface, and thereby gain the ability to easily create and try out any number of different sets of rules, to find out which is the most fun.
I hope this example shows how adding a small amount of abstraction can be helpful, even when writing code that will be thrown away at the end of the day. Rapid iteration is a common tool for trying to find the best fit for vague criteria (ie. making something fun/exciting/etc.), yet the discussion around it seldom explores the benefits of using abstraction to facilitate trying out variations*. I hope this post serves to highlight how selective application of abstraction is not only compatible with iteration, but can even be helpful.