Here at Basecamp it’s no secret that we’re in it for the long haul. From investing in employee benefits to holding off on tossing out old apps to replace them with new ones. Everything is set up so that staying in it for a long time gets you the best results.
One of the things that’s most interesting to me at Basecamp is that we wear our legacy applications as a badge of honor. The very first Rails application ever built still exists as Basecamp Classic. That is the application Ruby on Rails was both created for and born from. It’s easy to forget the weight of that sometimes.
There is something very special about getting to work on the first Rails application. You can see how the Rails framework was built out of necessity and how it has since evolved over time. The Rails framework will continue to be guided by the real-world needs of our applications and now scores of others.
In programming, there is often an obsession with using the latest and greatest technology. Programmers view the use of edge technology as its own badge of honor, and are quick to throw away legacy applications. We don’t do that at Basecamp. We move forward while not forgetting and discarding our past. Programmers don’t put enough weight on the importance of legacy applications and systems. They wonder “why would someone write code this way,” without understanding the history of how the code base evolved. A legacy application can actually teach you more because it has lived in a way a new application has not.
Legacy applications have users and data and experience that edge-based software cannot. Features have been built out of necessity, rather than desire. Every application that makes it to legacy status can’t possibly be pristine. And that’s really something amazing. Building applications that become legacy means being able to learn from your mistakes over time, so that you can build something truly better in the future.
By now you may have heard that we are building a new version of Basecamp. From our previous versions we have discovered what works well and what does not. We’ve not only learned what’s hard to build, we’ve also learned what’s hard to change. We know that customers want fewer emails and more control over notifications (whether that be push or email). Although that would be harder to build into the previous version of Basecamp, we knew going into Basecamp 3 what pitfalls to avoid and to build push notifications in from the start. There are many more features that were molded by our past, but I don’t want to ruin every surprise.
This new version can only be as awesome as it is because it has been created from what we learned in our past. As we prepare to launch a new version of Basecamp, the older versions will continue to live on and will continue to inform our decisions, showing really how much love we have for our legacy.