Do you have a Ruby or Rails application in production for more than 4 or 5 years? Has the test suite crumbled to pieces because of too many broken or flaky tests that no one has time to fix? running the tests pays off no more and slows down your pace to production? Are you struggling to cope with tech debt accumulated over the years? Do you feel your app needs a lot of love that no budget will ever be able to sustain?
We feel you. We’ve been there. Many many times.
We have inherited several applications that lived through many years, passed through many hands, many brains, many development philosophies and toolsets, and many business and scope changes.
When people live through the years they collect experience, and become wiser; as we mature we become better. Applications, on the other hand, tend to collect crappy code, technical debt, and rushed features; as they get old, they become worse.
Old applications are awful to work with.
What if I told you that there’s a way? Let us tell you a story:
Mr. Thompson’s deal
Eight years ago, one of our very first and most dear clients landed a huge contract with one of the biggest luxury hotel chains in the world. For the sake of this post, we’ll call him Mr. Thompson.
Mr. Thompson asked for our help thanks to the recommendation of a mutual friend. He was in a dire situation: the deal was almost closed and they had already started outlaying a plan for doing a complete digital transformation for the hotels, involving the development of a suite of applications. But when he got to us, the whole operation was at risk. The deal was conditional to the successful shipping of the very first project: A time-sharing management application for several locations, with a set of complex domain rules.
Another team had been working on the application for almost a year and hadn’t managed to ship anything. We didn’t meet the team, but the code told us they were probably trying out some new, more functional code style and something like a highly decoupled architecture (along the lines of clean architecture). Our guess was, that as time passed and no features had been finished, the team started to fall back to more natural and well-learned patterns (eg. good old Ruby on Rails MVC).
So, when we took over the application, it had a mixture of coding styles (functional and stateless vs object-oriented); a mix of frontend tools (like Angular and React; rails tests with fixtures and rspec specs with factories; dead code, incomplete and ill-specified features; and a broken test suite.
To make things worse, the Product Owner was a very exigent guy who was already losing his patience.
Mr. Thompson needed to deliver. We needed to deliver.
What we did
If you ask Mr Thompson what he thinks of us he would say something like:
If there’s a problem with a customer or anything, they’ll stand in the trenches with us until it’s done.
So that’s what we did: jumped down into the trenches, and worked in the mud until we made something shippable out of it.
We defined a plan to gradually make the toolset converge (we picked good old ERB views with sprinkles of React where we needed frontend power). We also started slowly but consistently fixing the test suite: first by reducing the tests to the bare minimum, critical path only, and converging the toolset on rspec and factories. Once we got a solid base, we started to increase the code coverage. Lastly, probably the most important bit, was that we strategically shipped first those bits of the app that were more important and valuable for the business (eg: a reservation wizard).
Finally, Mr. Thompson closed his deal and we are still working together on the suite of applications for the hotel chain. After 8 years in production, clients still use the app and love how it simplifies their daily work. We upgraded that old, ugly application to Ruby on Rails 6.2 and Ruby 3.0 and we have an upgrade to Ruby on Rails 7 planned for this year.
Your old Ruby on Rails application does not suck
An application that has 8 years in production and is still helping to drive revenue, from our point of view, is a massive success.
Despite of having a convoluted code base, almost no tests, a mess of programming styles, and a hellish mixture of new and old tooling: it works.
This is spectacular. And has a lot of value in itself.
Do not throw that value away
Our strategy is a continuous improvement: “Always leave the code base in a better shape with every commit”. In the long run, this will make your app better, and it will age in good shape, like we do.
If you find this topic interesting, you can read more about how we take over old applications.