Methods, in full.
In Section 2 of the main paper we described our practice in a single short paragraph. What follows is the unabridged version: the principles that inform our work, the workflow by which we do it, and the limits we observe. None of this is novel. Most of it is not even ours. We cite, where possible.
2.1Principles
One author per thing. An application, a feature, a file: each has exactly one author while it is being written, and that author is obliged to stay with it afterward. Committees produce software that reads like minutes; solo authorship produces software that reads like writing. See Knuth on literate programming [1].
Fewer over more. It is easier to maintain two applications than four, and easier to polish two than to ship four. We consciously decline scope that we cannot commit to maintaining, and we decline it early, before sunk cost makes the decision for us.
The platform is not the enemy. Apple and Google have each spent several decades working out what a good mobile application feels like. We have not. When our preferences disagree with the platform, we adjust ours. Reading HIG and Material Design in full, every year, is cheap insurance.
Interfaces are arguments. Every screen we ship is a proposal for how the reader should spend the next five minutes of their life. Good proposals are honest about what they are offering, conservative about how many things they ask for, and brief.
2.2Workflow
We follow a loose cycle: notice a problem we have (or one we can watch someone else have), write a few pages describing the shape of it, sketch the interface by hand, then implement. The interface sketch is the specification; if the implementation disagrees with the sketch, usually the sketch is right.
Releases are checkpoints, not events. We ship when a thing is ready, not when a calendar says so. The cost of a premature release compounds: every defect discovered post-launch costs more to address than it would have cost to prevent, because there are now people relying on the defect. See Gall [3] for the longer argument.
2.3Maintenance
An application is not shipped; it is started. Maintenance is the rest of the work. Most published software erodes not because the code rots but because the authors look away. We have committed, within the constraints of being human, to not looking away.
Concretely, we budget a fraction of each week for revisiting applications we have already shipped. This is reading, not writing, most of the time: what is the code doing now that it didn't used to? What is it like to use, given the current OS? Writing is the cheap part; attention is the expensive part.
2.4Limits
We do not take on commissioned work. We do not sell our software to other studios to resell. We do not advertise in-app. We do not bundle analytics beyond the minimum required to understand crashes. We are a small team, and we assume that if these constraints become difficult to keep, the problem is the scope of our ambition, not the constraints.
For an address, see § A, Correspondence. For privacy and terms, see § B and § C.