I like coming up with new ideas or creative ways to solve a problem. I build projects as a solution to a problem that I identify. The problem with having a lot of projects is the failure rate in building them. There comes a point when the technical complexities of what you are working on are solved and the next part of the project is just wrapping everything together.
I tend to refer to this as the 80% rule
When working on a project I have found myself getting caught into a trap where 80% of the work is completed but the remaining 20% needed to actually complete the project feels unattainable. If you are working alone on something this is the biggest hurdle to jump past. So much of my time is spend in this agonizing period.
“The project is almost done I just need to do X to finish”
When do you consider something successful? When is the project completed? How do you determine when something is actually complete?
Often I find myself stuck in the last 20% of the project wanting to make the thing perfect before it gets released. The fear of success and the fear of failure are paralyzing. This keeps the unfinished projects on a shelf occupying the brain space that would otherwise be spent on something far more productive.
When do you consider a project a failure?
A project that gets stuck in the final stretch never produces an outcome. The results are never delivered. Part of the struggle for me is that a project can not fail if it never releases. This is how I trick myself into not finishing anything. That fear of both success and failure causes a stagnation to occur. So now I am trying to rethink and change how I define the goal posts.
Let’s say that a successful project is something that is shipped with a minimal set of features. The minimal viable product or MVP is considered the first release and the first version of the project being completed at 100%. Next we will make the project a “failure” if we do not ship the MVP. The last thing that needs to be resolved is the fear of both success and failure of the project.
This concept of the fear of success has been something I have struggled with constantly. But it only surrounds itself when it comes to my own personal projects. These are the projects that I feel a strong connection to. I want to showcase my best work and show how great I can do things but that is also the problem. By trying to make the project perfect I end up not working on it at all and instead allow myself to get stuck in an endless cycle of crashing at the 80% spot.
Avoiding the 80% trap with accountability and documentation
Working on a project as a single developer is challenging, one of the things that makes it difficult is the lack of accountability outside of yourself. It’s very easy for me to disappoint myself by not hitting a deadline I have set or a milestone I created on a project. When you have someone else involved in the project you suddenly have someone waiting for you to complete the work that you promised to deliver so they can keep working on their part. While it’s not always possible to work in a team or have someone that can hold you accountable I have found that keeping a blog about the project to be the most helpful compromise to not having a teammate to pair accountability with.
Writing into the void that is the internet gives me a place to talk about the project that I am working on, the goals I want to achieve, and the milestones that I am setting out to reach. By writing these things out you make a commitment to more than just yourself. There’s a chance that you never meet or talk to any of your users. The idea that they exist and are waiting for the next update is enough drive to keep me going.
Documentation is the other important step to building successful projects. When you are working on a passion project it’s easy to keep building and never document what you are building. I am very guilty of doing this a lot even though I practically preach the power of documentation. From my personal experience the projects that I have completed successfully were also the ones that I took the time to write out the documentation.
While it may not be the most glamorous part of the project, writing out what you want to accomplish and breaking that goal down even further is what has helped me overcome the failure at 80%.
Top comments (0)