There’s been a few articles that have inspired me to think about shipping software differently these days. The first was from a great blog Signal vs Noise.
Shipping beats perfection.
Be open. Share your work.
Anybody can fix anything.
–Khan Academy’s development mantras are stunningly simple and powerful.
The next post came from a great developer I seem to admire more and more, Tom McFarlin. Tom hits the nail on the head when he says,
Straight up, one of the challenges that I’ve had my entire career is feeling that my code needs to be perfect (which, admittedly, is an arbitrary definition because perfection is some internal metric that I have for myself) before I can ship it.
He then goes on to say that,
Perfection isn’t even attainable – why is that our goal?
And it got me thinking.
I’m somewhat of a perfectionist. Not a complete perfectionist, because there’s a time and place for it in my head. But a perfectionist in the sense that there are some things that I insist on achieving perfection. The question though is why? Why do we think that perfection is the goal? What is it in us that gives that internal metric to being perfect?
I’m going to take a look at this with shipping code. A big part of my day is building and shipping code. Sure, it has it’s own processes and steps to make sure that code is developed, tested, and deployed. But each step is just the next step to shipping code.
When developing code, I almost always start out with junk code. My goal at this point is to just get the concepts of the task at hand and get them working. I’m not to the point of looking at speed, I just want to get it working.
Once I’ve got it working, I then go back and see what sucks. A lot of time it’s CSS, so I can refactor the heck out of it. I can combine margin, padding, and border elements. I can refactor further to where I have a more general class and in my PHP/HTML I can throw in these new classes.
When I’m done, I’ve almost rewrote what I started out with. It’s been refactored (sometimes too far). Perfectionism? Perhaps, or maybe that’s just writing quality code.
The code has to be tested. So it’s typically tested by another web developer and a quality assurance person. Both of these people are looking at the code in different ways. The first, a developer, is looking at it to make sure I’ve followed proper best practices we’re trying to keep with. While the QA person, is looking from the browser to make sure it works in a variety of browsers and operating systems. This is the crucial part of the process because if they run into something, I’m going to fix it before the day is done. When all looks good, I get a “shipit” on the pull request in Github and I’m ready to deploy.
Finally we deploying the code. This has to be perfect as well (at least in my head). I’ve tested the deployment to our staging server and when everything looks good, I’ll deploy it to our production server. In the event that something does go wrong, I’ll have to pull back those changes and frantically pick up the pieces so the site is still running.
But I thought how does that make my perfectionism bad? Well I see that it slows down the process. In many cases during the initial development of something, I could easily think too much into a certain task that before I know it, I’ve wasted enough time to drive any project manager nuts! If I can catch myself doing that, it’s better to sometimes leave the task where it is, commit what you have and see if it still makes sense farther down the rabbit hole.
The point at the end of the day though isn’t about perfectionism, it’s about shipping code. I am pretty sure that every developer out there likes to ship their code. When it doesn’t ship, it can be at times taken to heart. Shipping code doesn’t have to be about making the next Facebook or Twitter. It can be as simple as making some .htaccess settings to your caching strategy. It can be fixing a small bug that you happened to found. The point is to ship software. Don’t wait to have your code be perfect. If you wait for that to happen, you’ll be waiting forever.