How many times have you looked at a code base and dreamt about how much better life would be if you could just start over from scratch and re-write that sucker? On the surface, a re-write sounds like the optimal solution to making your life easier and solving all sorts of problems. We find ourselves thinking this all the time, specifically:
- If I could only take the time to ditch this slow-to-compile Java code with Ruby on Rails, we’d be shipping features at 10x the speed
- A re-write will enable us to cast away all the crufty code we wrote while rushing to get our 1.0 built
- We understand the problem so much better now, a rewrite would enable us to create a new design that would be infinitely more manageable
Re-writing software from scratch isn’t as awesome as it sounds
The truth is, re-writing a large code-base is super risky. Joel On Software has a great write up about why you should never re-write code. Major highlights include:
- The production code you have today has been used, tested, and it works
- There is significant time and effort on the part of both a developer and the end users to get code into a working state
- The reason the production code you have today is ugly is because it evolved into that after years of taking into account all the bugs, new requirements, and edge cases that you couldn’t possibly have known about or thought about when that code was first typed in
- There is opportunity cost to taking the time to re-write a code base because that means for the duration of the re-write, no new features can be added to the software
Flash helped make Gliffy successful, but has no future
Ok, so re-writing software is super risky and fraught with danger, but what if the platform your product is based on might not be around in 5 years? This is the problem that Gliffy faces today. Back in 2005, we felt that the best technology available to us for creating a feature rich diagram editor in a web browser was OpenLaszlo, which is a XML based markup language that compiles into Flash byte code. By leveraging the rich drawing capabilities Flash offered, we were first to market with a web based diagramming product that was feature comparable and just as interactive as any comparable PC or OS X native diagramming product. This resulted in Gliffy becoming a profitable company without any outside financing, almost immediately.
You want to be first to market, right?
Yes, and no 
- Flash isn’t supported in iOS devices
- Android is dropping Flash support
- Google Chrome support of Flash on the Mac seems to add new bugs that are out of our control in every new release
- Developers aren’t really excited about doing anything related to Flash
For sure, Flash isn’t keeping up with open standards. We could easily write a whole series of blog posts about all the hassles, bugs, and, quite frankly, the pain we’ve been through trying to make our Flash-based product work as it should, but that would be way too depressing. Rather, we want to focus on the road ahead, which for us, is about “creating great HTML5 tools for the future.”
If that last part sounds familiar, it is because that was a comment Steve Jobs made to Adobe during the “Flash Wars” of 2010“. So here’s what we are up to…
HTML5 to the rescue! But how given the risks of a re-write?
1. Build a rock star team
Starting about 18 months ago, we begin building up our client side developer team with some of the best Javascript developers in the industry. Given the tight market for JS developers right now, this is a pretty hard thing to do. We designed a hiring process that is a well oiled tallant machine that has helped us recruit and retain the best. It also helps that Gliffy is a fun place to work.
2. Speed up development time
OpenLaszlo, the language Gliffy was first written with, compiles to Flash byte code. Even on the best laptops money can buy, we were seeing up to 30 second compile times between making code changes. By moving to Javascript / HTML5, a slow compilation step is no longer needed, and the code/test cycle is down to 5 seconds or less.
3. Phase in HTML5 features to our users to reduce risk
There are too many risks associated with shipping a full blown HTML5 editor all at once to our paying customers. In addition to the risks related to total re-writes as highlighted above, HTML5 doesn’t work at all in many of the web browsers currently supported by Atlassian and frequently used by our customers. In order to best serve our customers AND get us onto a new technology stack, we decided a phased approach was best. We’ve accomplished this by breaking up our HTML5 efforts into two distinct development phases, and the Gliffy Flash powered editor will remain available and supported until Atlassian ends support for web browsers that don’t support HTML5.
- Phase 1 – As a part of the Gliffy Confluence Plugin version 4.2 that went out on April 5th, for users of HTML5 supported browsers, the static image shown on Confluence pages is now replaced by an identical HTML5 rendered image. This milestone involved significant work, focused our efforts, and helped us get product shipping sooner. Phase 1 also comes with a few nifty features that our customers will love, helping to reduce the lag time between feature releases.
- Phase 2 – Later this year we will release a full blown HTML5 Gliffy editor that is built upon the work from Phase 1. Anything we learn from the product shipped in Phase 1 will get rolled into Phase 2, which will help ensure a more stable product is available for our customers.
Why should you care about HTML5?
Here’s a quick video showing how HTML5 Gliffy diagrams will immediately save you time.
http://www.youtube.com/watch?feature=player_embedded&v=H6FYXI1VsDI
Get HTML5 Diagrams in Confluence today!
Install or upgrade Gliffy in Confluence instantly using the Universal Plugin Manager, or download version 4.2 of the Gliffy Confluence Plugin from from the Atlassian Marketplace.