Throwing away code

Ever get an idea in your head, and it seems like it will solve all your
problems in your app? If you could just do this one thing, rainbows will
sprout and unicorns will prance and sing?

Ideas turn into requirements, requirements sprout into little code
snippets, code snippets grow together into features. The problem, as you
might discover, is that sometimes these requirements can be too numerous
or sometimes just flat out wrong.

It’s ok to throw away code when you figure out your requirements are wrong. Let me give you a recent example from tweet
hopper
:

Sharing is nice

Tweet hopper has two pieces two it, a twitter job running daemon and the
website. There is a lot of classes that overlap from one app to the
other, and I am trying to keep test coverage up. The natural thought was
to move the shared models and shared specs to submodules and keep them
in sync. The more I thought about this, the more it sounded like a
win-win, I mean how could code sharing go wrong?

I soon found out why separation of concern is an important thing! As I
moved one class and specs over, I soon realized that callbacks and tight
couplings were going to be a nightmare. I was committed at first that
this was the right path, and I should work to decouple and test pieces
better. Moving and separating code can be a deep, dark rabbit hole.

Know when to fold em…

After two and a half days of moving code, running tests, finding
failures, moving more code, rinse and repeat - I decided that this
wasn’t the best approach. While decoupling code is a great thing, I
didn’t have the test suite to back up my work. I decided before I was
too deep into the project that it was a good time to scrap things and
re-examine the approach to the issues I wanted to solve. Be skeptical
of your solutions until they work 100% for you
.

Submodules had already been setup, code commits were in the master
branch, so this was a wee bit more of a cleanup job than normal. In the
end, it was better to revert things and spend more time doing research
on other ways to approach my core requirement of getting all the code
working together in one spot.

Spike!

When I looked at the code base and took daemon-kit and AMQP out of the
equation, I started to look for better queue options. By looking for
something more integrated into a rails app, I would be able to move all
my code into one easily tested spot.

After a week of research and reading, I realized resque
^1^ might fit the bill. Since resque integrates more directly into the rails app, I can submit jobs from the web interface
now - allowing new features I want. With multiple queue support and easy
command line priority setting, I can now easily prioritize jobs and
maybe increase run frequence on slow jobs.

The single biggest gain is that the resque system had a worker forking
system in place to keep memory leaks at a minimum - an issue I’ve been
fighting unsuccessfully in my tweet hopper daemon code for months now.
By tossing out other ideas and previous code, I found a possible new solutions. Ask me again once stream.twitter.com is out of alpha for
user authenticated calls!

The moral of the story

Don’t be afraid to question assumptions and requirements, even if they mean you might have to start over on a lot of code. Less code, one
git repo, or easier testing can all make coding smoother in the end,
despite initial time loss for tossing out code.

Links

[1] Resque blog post

Join the Meteor Club

and get my best tips and tricks right in your inbox!

Are you an advanced Meteor.js developer?

Josh Owens

It all started with an Atari 800XL, but now Josh is a ruby and javascript developer with 10 years of professional experience. His current love is Meteor.js, which he works with daily.
Cincinnati, Ohio