When I first have an idea for a project, my instinct is to meticulously plan it out.
I do my best to go against that instinct. Sure, it’s important to think about structure, and of course it would be nice if the code was reusable, but all of that is useless if the thing doesn’t exist in the first place. When I pour all my ideas out of my head into Vim they typically end up as disgusting spaghetti code. However, it’s exciting, mostly functional disgusting spaghetti code and that’s all that matters when you’re starting out. Make the thing exist.
Recently I did a total rewrite of the codebase for our new product Social Prompter. The two main parts of the service – a live streaming tweet screen and a photo booth – had originally been developed separately for separate purposes. Over the course of a few months they had both been touched by numerous freelancers making numerous hacks and were getting unwieldy. The newest iteration of the photo booth was functional but unreliable thanks to unstable 3rd party software (I’m glaring harshly at you, Canon EOS Utility), and if we were going to sell it as a product and position it as a competitor to more established services it needed to be a lot better.
So we had a great brainstorming meeting with a few new ideas and a few snazzy upgrades and off I ran to my corner to hack it out.
- Make it more reliable.
- Make it easier to set up new events and update ongoing events by basing each event on a central codebase.
- Make it compatible with version 1.1 of the Twitter API.
I want to talk about #3 here because it had the most interesting process, but I don’t want to ignore 1 and 2 in case you were curious.
- The amount of 3rd party apps was reduced from four to two.
- The skin for each event has its own folder with CSS and images, but the functionality is in a central “core” where they all pull from.
There, done. Now onto the good stuff.
So naturally, when the time came to rework Social Prompter’s Twitter feed the plugin bug began nagging me again. First, though, I needed a proof of concept for my roll-your-own-backend version of the plugin, and that’s where the spaghetti code from the first paragraph comes into play. With brute force and minimal elegance I made it happen, and if you like you can read it (and maybe laugh at it) here. The concept is simple really, but knowing a simple concept in your head and seeing a simple concept updating real tweets about puppies (#puppy is the sample search, if you didn’t check out the code) are entirely different things.
You know what is a perfect example of code that is abstracted and reusable? A jQuery plugin. And, we’re off.
The point of this post is to point out the importance of not thinking too far ahead. I knew from the beginning that I wanted to create a jQuery plugin for this functionality, but the thought of jumping right into that scared me off. Even the thought of forking and hacking up someone else’s work made me nervous because I wasn’t familiar with its nuances. I was, however, extremely familiar with the nuances of my thrown-together-from-scratch version, so when it came down to combining the two there was much less to wonder about. Even though plugin development was relatively new to me, knowing exactly how the code should function once it was working helped me a lot with understanding the structure.
It would be great to have an idea and to be able to put it in its final form the first go-round, but we all know that doesn’t happen. It takes iteration to perfect a system, and even before iteration it takes a lot of experiments to know what direction to go in. Next time you have an idea, don’t spend too much time figuring out how it should be structured. Get it all out; you can make it pretty later.
This post originally appeared on thesmackpack.com.