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.
Marlon
on 11 Sep 15Hello,
How do you manage legacy software stack ? Like a Rails version that is not supported by community anymore or a Linux version which the “vendor” do not release patches and updates anymore?
Regards,
Marlon
Marcos
on 13 Sep 15Agreed with Marlon, I’d love any insight Basecamp folks would be willing to share. In projects I’ve worked on, the cost of upgrading to cover basic security is always greater than I expect. I actually asked a similar question in response to David’s #UntilTheEndOfTheInternet post a while back, but never heard back.
Eileen
on 13 Sep 15@marlon and @marcos We don’t currently use any non-supported Rails versions. Some aren’t supported by the Rails team anymore but are still community supported. Since we wrote Rails and know it’s internals, it’s less difficult for us to keep up if that stopped being supported. This also doesn’t mean we don’t update the legacy apps, what I mean is that we continue to support our legacy apps, even if that means updating the software stack. For example, while Basecamp Classic will continue to run forever, it’s not running on Rails 1. Additionally we have teams for that, specifically I’m on the security and performance team, so part of what I do is keep up with vulnerabilities and assess when and what needs the software stack updated.
Marcos
on 14 Sep 15@eileen, that’s awesome! (Both in the “wonderful” and in the “awe inspiring” sense.) Investing in legacy apps to that extent is no easy task. Seems like there’s some great publicity/customer re-assurance available in the “we don’t just keep the lights on, we’re definitely still watching to make sure things are secure” side of Basecamp’s legacy app story.
Sai Krishna
on 17 Sep 15What a beautifully written article and a much more beautiful subject. Anyone who considers themselves a true lover of software, like I do myself, will tell you how technology is usually associated with the fastest and the latest, whilst forgetting that even in technology, like songs, there are classics.
Just because a software (song) is legacy, not functional (not relevant), doesn’t take away from its beauty. Thank you for writing this article Eileen.
This discussion is closed.