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.

The challenges:

1. Make it more reliable.
2. Make it easier to set up new events and update ongoing events by basing each event on a central codebase.
3. 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.

1. The amount of 3rd party apps was reduced from four to two.
2. 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.

The original version of the tweet screen used Inge Jørgensen‘s excellent jQuery LiveTwitter plugin, which is a very simple and robust way to create a streaming Twitter feed based on a particular search term. Unfortunately, Twitter’s forced switch to API v1.1 on March 5th, 2013 requires all calls to be authenticated, and that means no more Javascript-only Twitter feeds (lest you risk exposing your secret keys). When I read about these changes I flirted with the idea of updating Inge’s plugin but it never came to be.

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.

The one issue this code doesn’t address, though, is #2 in our list of challenges. The search term is hardcoded in the file, so there would be no way to reuse this code between events without having to make different copies. Does that make this was a total waste of time, since it isn’t actually usable in the product? Of course not. There’s a lot to learn from this code. For one, you can see that my programming foundations are in Java and C++, and I learned to create infinitely looping programs with driver functions and recursion rather than with Javascript affordances like setInterval and setTimeout. It’s like a little glimpse into my brain, and I find things like that fascinating. More importantly, though, I learned that my concept worked and if I could find a way to make it more reusable it would be perfect.

You know what is a perfect example of code that is abstracted and reusable? A jQuery plugin. And, we’re off.

Over the time I had been using the jQuery LiveTwitter plugin I had developed a few small qualms with it and had actually considered rewriting it more than once. Now that I had a foundation that worked with the new API, I set out rewriting it for real. Using the basic structure of the original plugin, I added some of the new features I had in mind (along with a few TODOs for future ideas) and used my backend interface in place of the Javascript interface. The result was jQuery Tweet Machine, which you can now find on Github.

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.