Perfection Is Useless

Shipping early and improving later is a huge competitive advantage, but our instincts often get in the way of that.

One of the most important things we teach the junior programmers who join the Semaphore team is the mindset of shipping in small iterations. This is a simple concept, however there’s an inevitable misunderstanding that stems from the subjective ideas of “small”. Thus, in practice we need to teach by example what we really mean by small.

When you’re inexperienced, the desire to do and show your best work often leads to perfectionism. In programming, perfectionism often manifests itself as “I haven’t submitted my pull request because I haven’t completed everything yet”.

Perfectionism is at odds with the goals of developing business software — giving something useful to users, preferably sooner rather than later. Perfectionists create imaginary obstacles and never end up building anything.

Recently, a pair of junior programmers was building a new reporting screen for our marketing team. The screen needed to combine two sources of data for a given time range and present a paginated view of results. The team that needed the report has never seen the data this screen would provide. Would it hurt if the first version of the report did not include a date picker and pagination of results beyond the top 25? Hell no. So, we encouraged them to ship the screen without the date range and pagination. The initial results provided more than enough value and ideas for improvement. The marketing team had some data they could work with while the developers continued working on the remaining tasks.

The crux of the matter lies in decomposing a task into minimal useful pieces. Next, you estimate the complexity of each piece and communicate expectations with the “stakeholder” (customer, client, product manager, or feature user).

Say a designer has recently updated several details that affect four distinct screens. Would it be best to integrate these changes in four separate pull requests, or one? This is where complexity, i.e. the time it would take to complete each one, needs to be considered. If they would take a day each, four separate pull requests are probably best. If all of them together would take you less than an hour to complete, go ahead and combine them all into one pull request. Are three tasks really easy, but the fourth one requires additional input from the designer who’s having a day off, as well as more time than all others combined? Best to please your users with what you can finish soon, and then do the last thing separately.

Shipping early will often provide you with surprising feedback. Perhaps the initial version is so good that nobody really needs the stuff that’s “missing”. Or, the whole idea didn’t really deliver what was expected and needs to be reconsidered. The goal is to learn and help others. Just keep moving.

This post originally appeared on Semaphore blog. If you liked it, 👏 to let me know, and post your thoughts as a comment. Thanks!

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 311,804+ people.

Subscribe to receive our top stories here.