Bugrocket's Rapid(-ish) Development by Ryan
I started working on a side project in June of 2009 that would eventually become Bugrocket… sound like a really long timeline? Well, it was strictly a toy project – a handful of hours a week at most. The project is a bit of an unconventional fit in a story about ‘Rapid Application Development’.
Frustrated by our bug tracking solution at work, I quietly began paying extra attention to how we used it and noting what worked and what didn’t. It took a while to fully understand the intricacies, though, and at first I didn’t really know what I was trying to build. I mostly just did what was fun. But as I went on I started to understand more what a team like ours needed in a bug tracker (and it wasn’t 10 million fancy AJAX-powered features).
The real tricky parts were all the re-writes and changes of direction that came out of that realization. It must happen to most bug trackers (and workflow tools in general). I implemented everything I could think of. Custom statuses (even custom colors for statuses!), custom fields, due dates, graphs, making it possible to track your time and have discussion topics and a wiki and a ‘support email’ consumption engine… you name it. One of the old repos even has evidence that it was possible to keep all your code with the app (and it would pull new code whenever you tried to reference a commit in a comment, or something equally crazy)… It got way out of hand, and it was never going to get done - even from a toy project perspective, it looked never-ending. I did, in theory, want to actually use this bug tracker at some point.
Then I stopped, realized the monster I was creating, and started doing the opposite. I was being a little too ‘rapid’, just throwing code around - so doing the opposite meant cutting everything. I deleted code until I was all the way down to the simplest thing I could conceivably call a bug tracker. Without MongoDB, I would have easily racked up over a thousand database migrations on this initial cycle alone.
Removing things is not so bad most of the time, but sometimes I would remove a feature (like priority), only to discover you really do need it! Or I would have a really complex feature like tagging, with advanced search and filtering and auto-complete, and strip it down into the simplest thing that could work - changing it fundamentally in the UI and the database. MongoDB made all this amazingly simple and straight-forward. I would even say the ease and light-weight feeling of changing my schema on the fly in MongoDB heavily influenced Bugrocket’s philosophical direction in general. Low barrier, low hand-holding and very high flexibility.
To break it down: Over the course of the first 6 months I had built and then completely torn apart the entire project. Later, a major re-write from Sinatra to Rails 2.3.8. And lastly, once the project seemed to have some legs, I finally ported it to Ruby 1.9, Rails 3 and Mongoid (up until then I was using the Ruby driver in a very hacked-together custom ORM). All these stack changes were simply not constrained or hindered by the database at all. It wouldn’t have even mattered if I switched languages, let alone web frameworks or ORM’s.
Today, Bugrocket’s database is simple in comparison to it’s past self. If you rewound time you would see it sprawl out and contract several times in different directions. The development of the app as a whole probably can’t be considered ‘rapid’, but those 2 hour sprints every-which-way certainly were.