Shitty First Software Drafts

May 2015

Writing is known for shitty first drafts. To arrive at the final piece it undergoes a transformation from loose and undefined to something concise that clearly communicates an idea. The best writing is written multiple times from a blank slate: from shitty to good, from good to great, from great to terrific. Creative individuals such as painters, writers, composers, choreographers, .. are all notorious for throwing away pieces of work that just “don’t have it” and start over until they capture the essence. Software is blessed and cursed by the fact that it either works, or it doesn’t work. The tests pass, or they don’t pass. Other creative disciplines, are blessed and cursed by the fact that completeness is vague. It’s tempting to get away with ‘good enough’ code, just enough to make the machine do what we need it to. However, unlike other creative work code is not just for interpretation by humans, but also for computers. In “Bird by Bird” Anne Lamott describes how her fiction writing starts and ends with the characters. Through writing, much of which is thrown away, she discovers the them and their personality. Once she’s finally gotten to know them, the story can unfold. The same thing happens when solving a software problem as we explore the problem domain by writing code: we build classes and observe the relationships between them, think about different layers to solve the problem at and look for problems in a design. Will it scale? What if this fails? Can I make it easier for someone else to understand this? But all too often we don’t exploit the knowledge we acquire as we work on a problem by taking a step back with everything new we’ve learned about the problem to start with a clean slate and attempt to solve the problem again. And then again. We simply stick with the first thing that works, because we can often get away with it. You can observe the best developers go through the same self-loathing creative process as writers: rigorous refactoring until the problem and solution is expressed in the simplest possible way. This solution doesn’t just have fewer bugs, is easier to maintain and review, but also serves as an excellent mental model for the next person who has to touch the code. A half-arsed solution will damage their understanding of the problem and solution, leading to more cruft as the misunderstandings stack in the code. This means the code can organically evolve from a simple foundation.

Use git reset HEAD —hard, and use it often.

You should follow me on Twitter here.