When applications don't age well and are near death...

Most of us prefer to write applications with the latest technologies. I don't know anyone who begin programming their projects with PHP 4, Rails 2, Java 2 or other outdated technologies. We shouldn't! Most of these things are deprecated, and we the developers should be favouring faster and more secure ways to build applications.

Well-designed applications might be there for years, though, and if these aren't maintained, there is a huge probability that developers will have a hard time creating new features. When this happens in an early stage, it means refactoring. But if this happens within years, one should consider switching. That was my case.

Grief

I was working in an application designed with Rails 2.3 in mind. It's safe: previous developers used security patches for almost all the problems that can be found in old Rails versions, it has ugly but functional form filters to prevent XSS and other hacky things. Those things are good because nobody wants to see an application from 2009 failing with all its important data, but I've been cracking my mind trying to implement three new features on top of it. It just seems to be impossible.

What can I do? Will it die? Nooo...!!!

Complaining isn't an option. I have to escape from this and become the man with a plan. Enter the 5 stages of grief:

Denial

I hereby refuse to work with an unmaintained database, a dirty codebase and a hacky design. I can't accept it. I deny it!

The first thing I needed to do was to analyse the entire database, creating a new data model and dropping all the fields that aren't in use anymore. Those fields create overhead and one usually ends up with lots of null values. Not what I want.

I was working with Rails, so I can make use of scaffolding to create a new codebase. Rails 4 has support for foreign keys and some features that are now considered standard but that were very advanced by the time of Rails 2.3. This codebase will be a standard Rails codebase, though, and I do not want that. I wrote the generators in a file but didn't execute those until I completed the third and last part of my denial plan.

It's completely understandable to not have design guidelines when we begin building an application. This one is from 2009, and customers have clearly stated that they like their application. The last part of my denial plan is to fire up Atom and write at most 10 views: index, dashboard, list, show, new, edit and login. Then I'll generate templates around those views and replace the ones included with rails g scaffold. It's a neat, easy to use trick.

Anger

How come this project was up for so long without being modified! I want to destroy it!

We destroy things because of anger. This is the plan: to destroy the previous database by making it look like the new one. That means rebuilding and reprocessing lots of data that has changed over the years.

Once the database has been rebuilt, one should create a diff between the previous data model and the newly generated one, and check if it fits in our models, controllers and views.

I also took the opportunity to refactor views and put the view logic in helpers. Remember that the process itself will make us feel anger, because it's painfully slow.

Bargaining

Can't I just stop complaining? I now have a shiny new data model and the design has received a facelift. Should I focus on what controllers do instead?

Of course, this application is not just scaffolds, that was the easiest part (except for databases, nothing is easy when it's about databases). One should be careful when rewriting controllers. I recommend to begin mapping routes to their RESTful+shallow counterparts and deleting unneeded ones. I had to go back and forth because I deleted something that wasn't needed.

The already good-looking views will become useful ones naturally: just ensure to check all the links and forms.

Depression

I didn't write tests :(

Write new tests. The old ones won't be useful anymore. Sorry, it's depressing, but it helps. And remember, testing wasn't popular when Rails 2.3 was hip. We're building something better.

I really can't write something useful here because I'm not good with testing. Nevertheless, a good recommendation for you would be to read Aaron Sumner's Everyday Rails Testing With RSpec.

Acceptance

At this point, I spent two weeks with a well-designed, fully modern, bug-free application. This will probably last for the next six years, and then someone will rewrite everything to suit HTTP/2, JavaScript ES2021, Bootstrap 15 and jQuery 20.0. And no, it won't work on whatever Microsoft brings to the battle.

Or perhaps it has lasted for six years with a loyal customer base that will bring enough resources for us to keep it updated. The future, however, isn't as obscure as when we started.

Footnotes

Names, dates and real versions have been supressed because I wanted to make it look like I'm being harsh on this application's previous developers. The truth is that this application isn't poorly written! Besides the fact that I couldn't compile Ruby 1.8.7 with my modern Linux distribution and that some gems couldn't be found in their original repositories, there were no actual problems with the code, it was very straightforward.

BTW, Thanks to Alex, Fernando, Patrick and Hendrik for their help and support on this crazy thing. I know they won't be disappointed with the results.

All the best!