The following articles discusses a common pattern that software engineers fall in related to leaving a project moments before crossing the finish line.
https://austinhenley.com/blog/90percent.html
Stick figure relaxing with their legs propped up on a desk in front of a finish line.
I just finished a project.
We spent 4 months building a software system, running experiments, writing an academic paper, and submitting it to a journal for publication. So now we are done. The end. Right?
No! This is what I call stopping at 90%.
The core project might be complete, but there’s still plenty to do. If no one knows about it or won’t give it a chance, then it’s as if it never happened. It’s a false finish line.
But it isn’t specific to research papers. It can happen to any project: the iOS app you released, the personal repo that you put on GitHub, that report your boss asked you to do, your side business of painting cute puppies, etc.
I see this problem everywhere and no one seems immune.
It is common to stop at 90% since the core project has concrete deliverables that can be easily measured (e.g., did we improve the performance of the system? Did we submit the paper?) where as the remaining 10% is far more difficult to track and often has no clear stopping point.
What are some common activities to go from 90% to 100%?
- Present the work to other teams.
- Broadcast an email with the takeaways so that the rest of your organization knows about it.
- Put the code somewhere that your coworkers can make use of later.
- Write a blog post about it. Post it on Twitter, HN, and Reddit.
- Sketch out a next-steps document, even if you have no plans to continue, that explains what you would do next and why.
- Look for adjacent projects that could benefit.
- Find someone that can poke holes in your work, then go address them.
Evangelism, documentation, and polish are often just as important as the core project.