The Three Phases of Software Development
Table of Contents
As Depicted Through 30 Commit Messages Encountered by Our Community
In our recently completed Mac Dev Survey, we asked participants for the best commit messages they'd either seen or written. To be honest, all we expected here was some light entertainment. What emerged from the responses, however, was something far more revelatory. We think this data outlines nothing less than a complete methodology of software development, practiced in the wild but hitherto undescribed in the annals of academia! Here's our attempt at bringing this methodology the attention it rightly deserves.
In the book The Hitchhiker's Guide to the Galaxy, Douglas Adams writes that every major galactic civilization passes through three distinct phases. He calls these the How, Why and Where phases, and exemplifies them by the questions "how can we eat?", "why do we eat?" and "where shall we have lunch?". In a similar manner, the survey responses show us that software development proceeds iteratively through three recognizable phases. We've chosen to refer to these phases as Denial, Bargaining and Bewildered Acceptance. As we'll demonstrate shortly, these phases can be characterized by the statements or questions "this doesn't work!", "please work!" and, finally, "why does this work?".
Let's throw some more light on the individual phases, starting with the phase of Denial. Characterized by the statement "this doesn't work!", at this stage, the developer clearly doesn't expect their carefully committed code to perform very well. Here are some example commit messages from the responses to our survey:
- "I don't think this works"
- "Please fix later"
- "you shall not pass... tests"
- "This will come back to bite us"
- "Somebody fix this."
- "This should not be committed but can not argue with manager"
- "Fix bug but its not work"
- "This change may not work for everyone."
- "Well that's not gonna work"
- "Do not merge this"
Following the Denial phase, the developer enters the Bargaining phase. Manifested in the cry "please work!", this phase is characterized by the developer desperately wishing their code would function, but lacking confidence in their own ability to make it so. Instead, they resort to appeal to higher powers (perhaps including but not limited to Linus Torvalds, and their particular code reviewer):
- "Hope it doesn't break anything"
- "Bugfix (Second try)"
- "... 3rd try"
- "Semiblind attempt to fix customer's issue"
- "this one should work"
- "Hopefully, maybe, fix X, please?"
- "I'm tired, I need you work already"
- "This is the ninth attempt at rebasing"
- "Ok I promise this time it will work"
- "If this doesn't work, find me at the bar. If it works, find me at the beach."
3. Bewildered Acceptance
All things going well, the developer then proceeds to the Bewildered Acceptance phase. "Acceptance" because the code finally passes the tests, puts the right pixels on screen, or otherwise clears some esoteric barrier placed between a commit and its inclusion in the
main branch. "Bewildered" because, as our data clearly shows, the developer is rarely able to identify the causal link between whatever changes they made and the fact that things now function correctly. Indeed, the question most closely associated with this final phase is "why does this work?":
- "Not sure why but it fixes things"
- "magic, do not touch!!!"
- "it works, but shouldn't. plz help"
- "I don’t know why it works, but it does"
- "Does some stuff idk it works now"
- "don't know why but its fixed"
- "I don't know what i've done, but it works now"
- "I don't understand how this works, just don't revert this one"
- "and then a miracle occurred."
- "explain me if you understood my code"
Where do we go from here? Will industry consultants flock under the banner of this new development methodology? Will it give birth to an abundance of books, conferences and certifications, and bring about a new era in the so-called art of software so-called engineering? Most importantly, should you fire up the Tower Git client, whose visual drag-and-drop-friendly interface incidentally makes rewriting Git history a walk in the park, and reformat all your past commit messages to adhere to the workflow here described?