Identifying and Mitigating the Ninety-Ninety Rule in Software Development
Ben Halpern Nov 12
Eleven days ago, we were about 90 percent finished building the initial version of the DEV iOS app. And then I had a realization: We still had another 90 percent of work to do.
This is a phenomenon so common that it has a name and Wikipedia page: The ninety-ninety rule.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Despite feeling like we took a minimal approach from the start, we were slightly off base in the approach and I saw a lot of pain in continuing down that path. So, despite being this close to being finished, we started over.
I made this issue:
I want to propose a design adjustment which simplifies the initial version of this app to be released.
I propose we remove the tabs and lean in on this being an even simpler shell of the mobile web. All navigation will be via the web version of the app.
I'm seeing the last 10% of the existing approach as possibly resulting in another 90% of work. And it's not that we couldn't push it through, but I could foresee it resulting in a sort of maintenance burden we are trying to avoid.
So I think we should go with a stripped down shell that simply offers the web view, with web navigation to everything needed and a bottom bar providing back/forward and other utility buttons (view URL I'm currently on? Open in Safari? Etc.)
We are web focused, we already have all needed functionality on the web. I think we should lean in on a leaner approach and ship something that will at least work as well as the web.
As far as native functionality, I think we should support deep linking, push notifications, and other conveniences, but mostly try to launch something as simple as possible from an implementation perspective, and I think that is what I'm describing.
I know we put in a good deal of work in the current approach, but I don't think we should fall for a sunk cost fallacy. I think we've learned a good deal about what's been difficult, what's been easy, etc.
Final thought: If we go this way, it might be plausible that React Native or Flutter would be a better approach.
And then I spun up a proof of concept.
That proof of concept was basically enough. We went with a simple experience in order to launch a native iOS app. It does make use of some of the niceties of iOS, and importantly does alleviate a few frustrating constraints of only existing in mobile Safari land on iOS. Importantly, it also means that we’ve launched platform to grow from. We have crossed the chasm and can now learn how to provide the ideal native experience.
On Friday we submitted the app to the App Store
We knew that launching quickly rather than living in prototype purgatory was important. What was less obvious was how simple it was to throw out a lot of work and start rewriting the whole app in one night. This was a new one.
Almost all the code for the current app is located in one file, simply titled
The night that I realized we needed a shift, I actually began writing three versions of the app. One in Xcode/Swift, one in Flutter, and one in React Native. I also encouraged others to take part in the bakeoff. In this process, the truly native Swift approach always won out for me.
I wrote a bit more about this approach, and I maintain that we made a good call:
I also started a thread about the sunk cost fallacy at play, and got a lot of validating feedback:
Now that we have planted our flag in iOS land, it's time to settle and expand. Beginnings are far less important than middles. We want to quickly transition from this beginning phase to a new period of maintenance and growth.
Happy coding ❤️
Android coming soonish 🤖