A few people in our surroundings are discussing re-writing their web service and applications.
This is not a simple decision, in fact it’s not a wise decision either. In most cases a rewrite can take weeks or even months. Sometimes they’re never completed, and eventually abandoned.
..in fact it’s not a wise decision either
Monolithic applications
If your application is huge and monolithic, then I’m telling you not to rewrite it. Joel was right, and you’ll probably burn in hell if you don’t take his advice.
Our web service
Jidoteki adheres to the UNIX way. It’s a group of small applications which work well together.
Our frontend app is lightweight but a very important component of the web service, because it’s the first thing customers use. We wanted to rewrite only the frontend, but first we had to make a decision.
Timeboxing
As a test, we decided to timebox 16 hours for the rewrite (two typical corporate work days, or one startup work day), and I wanted to revisit progress at 8 hours, then decide if we’re wasting our time or not.
Some preparation
Before starting, we needed to validate the following assumptions:
If none of the above is true, don’t even think of doing a rewrite. You’ll regret it.
I wrote down a plan with a list of tasks, features, additions, improvements, and public libraries we could use to speed-up a rewrite.
I estimated 9 tasks for the entire rewrite. Nine tasks, eight hours.
All of the above
Our original frontend app was written in PHP using the CodeIgniter framework (I know.. I know..). Unfortunately EllisLab seems to be abandoning the project or doing their own full rewrite (v3.0?). In any case, the framework was missing a lot of features and didn’t have enough well-written modules for us to work with.
We had struggled to implement even the most basic things such as websockets and redis-backed session stores.
We had written our own libraries for many things, which means we also had to maintain them. Re-inventing the wheel is stupid and a waste of time. Rookie mistake.
Re-inventing the wheel is stupid and a waste of time. Rookie mistake.
Node.JS
We chose to port the app to Node.JS, because we understand callbacks (hahaha). The list of npm modules for doing everything & anything is also phenomenal. This helped us avoid writing our own libraries except for very specific Jidoteki things.
Here are some of the modules we use:
Side note
Great thanks to everyone who writes open source code and releases it for the public to enjoy. We <3 you.
Stack Overflown
Even if you’re familiar with a programming language, it sometimes has some gotchas which can hang you up for a few hours. Often this is caused by a blind copy/paste from Stackoverflow without knowing what the code does.
Example this answer, which seems nice until you realize node-validator deprecated chained validations about 2 months ago.
..often this is caused by a blind copy/paste from Stackoverflow..
Don’t do that. Spend a few extra minutes carefully reading your language’s documentation and API when you’re stuck on a problem.
Count your hours
I can’t stress the importance of tracking your time. I still use a pen and paper, but there’s no wrong way to do it.
I like to split an hour in 4 blocks of 15 minutes. Whenever I lift my head from the screen, I mark off the blocks of time I’ve spent.
Conclusion
After 8 hours of coding, we were almost at the exact same point as with the PHP application.
I decided it was worth continuing to add some major improvements, and stopped at 14 hours.
This was a fun test, since now we have a much better application with much less custom code, and we can continue moving forward with new features.
If you haven’t already signed up for early access to Jidoteki, make sure you enter your email in the form below.