Here at tinyHippos we get to work on some awesome stuff, building a phone emulator that runs inside a browser forces us to push the boundaries of web development, morphing the browser to our wills. Ripple has had a nagging bug for a long time, although, not a show stopping bug, however it did take away from the user experience and was preventing developers from writing code in certain ways. None the less this bug was a thorn in our side and caused us to feel less than awesome about Ripple. People would rave to us about how great our emulator was and how much it was helping them solve their problems, but we could only focus on its shortcomings.
One morning we were talking about how to solve this problem when Brent mentioned a plan that he thought might work. We all debated and agreed that it sounded like it might work. As we talked, we started to realize that for this to work it would require a rather large refactoring of the entire bootup process of Ripple; basically a rewrite. We were about to put this on the backlog to forever rot when Dan challenged us to give it a try. Brent and I went off for the day to see if we could prototype a simple example of the idea to see if it would even work.
I would be lying to you if I said that we solved anything this first day. We spent the day with Ripple throwing errors, causing chaos, and crashing our browser. It was a challenging day and Brent and I left the office feeling spent and deflated. It wasn’t until Brent spent an hour or so that evening and ended up with a “working” prototype, that we even knew what we were attempting to do was possible.
Fueled by this small glimpse of success we hammered out the rest of the code to get it working over the next couple of days. The end result was our 0.4.0 release where we are now able to support some of the more complex mobile web frameworks.
Embarking on this path could be viewed as risky and even potentially wasteful. However, we find that by applying a few basic rules when going down one of these “rabbit holes”, these kind of exercises have helped us take Ripple to the next level. Here are the rules we use when we go exploring the unknown:
Try it: The best way to see if an idea will work is to try it! Breaking down the idea into a manageable chunk to prototype out will allow you to quickly see if it is possible. Keep the prototype simple but not trivial. The success or failure of the prototype should give you a good idea about the end result.
Timebox it: It is very easy to get lost while working on a prototype, it will feel like you are shaving a yak so it is important to timebox your work. At the end of the alloted time you should be able to give your idea a yes or a no.
Don’t be married to it: During our progress we deleted a lot of code. We were proud of that code and it was battle tested, under test and generally awesome. This code was the result of a lot of blood, sweat and tears and was hard to part with. Just because the code works and is in production, it doesn’t mean it should continue to live forever. The same can be said about your new code. It might have felt like a good idea, and you are a few days in and success is just around the corner, but not all attempts will be successful and the sooner you call it quits the better.
Pair it: Don’t go down the “rabbit hole” alone. Trying new things is scary. The entire first day Ripple was broken and not even close to working. A lot of times during that day we second guessed our approach and lost track of where we were. Having another person down in the weeds with you helps keep you from getting lost.
Filed under: Editorial