Most of us are familiar with the constant battle between shipping and perfectionism. We all want to get our products out-the-door and into the hands of the public. We also want our products to be pixel-perfect and beautifully coded. None of us want to postpone a launch forever, but none of us want to ship ugly work.
Where’s the healthy medium between Minimum Viable Product and the “Glorious Ideal?”
Love, Betrayal, and RESTful API Client Authentication*
*contains one of the above
I spent most of the past week with my head buried in the OAuth 2.0 spec, trying to figure out how to lock down an API that I hope will someday prove useful to lots of people. Compared to front-end design, building an API is tedious work, especially where security and scalability are concerned. There are other, faster routes I could take to finish this project. I keep asking myself: why is it worth it?
The project I’m working on would function just as well without OAuth. I could temporarily secure the API with a more primitive mechanism, with the intention of coming back later to make it more extensible. At the moment, I have no reason to believe anyone besides me will ever need to interact with our database. But I’m nagged by the feeling that, if I don’t start off on the right foot, getting there later will be a gargantuan task.
Every project has at least two competing obligations. On one hand, we must produce the best work that we can, for ourselves and for our constituents. On the other hand, we’re obligated to meet deadlines, budgets, design criteria, and other real-world constraints. It’s up to us to find the appropriate balance for our particular situation.
Determining the balance is more difficult on self-directed projects. My OAuth project, for instance, doesn’t have a strict deadline or budget; it can be launched whenever I deem it finished. The only way for me to avoid the trap of perfectionism is to set my own deadline and have a friend hold me accountable to it. Sometimes, imposing artificial constraints is the only way we can force ourselves out of decision paralysis.
In the end, I’ll likely finish the minimum functionality needed to launch the API, and leave the rest for after the launch. I know what direction the project will go in (or I think I do, anyway), and so I can lay the groundwork for future functionality without spending the time to build it completely. While it’s not a compromise that my perfectionist side will enjoy, it will get the project launched soon.
Launched is better than perfect; great work is better than lousy work. Here are some thoughts on navigating between the two competing interests:
- If you release a product early, it has the opportunity to start making money, which you can then use to hire programmers to help clean up the mess. Facebook would never have happened had Zuckerberg been overly concerned with scalability.
- Perfection is impossible to attain. Even the best ideas have potential for improvement. If that weren’t the case, there never would have been a second-generation iPhone or a social network beyond Friendster.
- When in doubt, trust your ability to iterate.
This is an ongoing discussion without an agreed-upon answer. Please, add your thoughts to the conversation in the comments below: