To many of us, our cars, motorcycles and push bikes are critical to our day-to-day operation. Even if we don’t use a car regularly, the taxi, bus, train or ferry network we use to commute is critical to our day to day living.
What would you think if you found out the car you were driving has not had a checkup, or at least an oil change in the last couple of years? Would you ignore your mechanic, or would you take your car in, for at least a rudimentary checkup when needed?
The idea of not maintaining your vehicle is crazy. All car owners know that this maintenance is necessary for a smoothly operating machine. Not doing the basic maintenance might not cause any problems in the short term, but one day in a year or so, you’ll go to start the car and it just will refuse to budge an inch.
So why is it that we all assume that running a web application on servers doesn’t need this sort of checkup? Quite often a company will spend many times more, maybe 10 to 100 times more, building a web application than they will on the purchase of one company car. Yet we almost give no attention to the ongoing maintenance and support of that web application.
Every running web application needs maintenance. Just like your car or bus, most applications will be “running fine”… until they are not.
And when they are not, lots of things can occur:
- The site could be completely offline, allowing no one access.
- Worse, the site could be partially on line and with you losing valuable data as it constantly crashes.
- Even more sinister, the site could be hacked silently due to a long term, unhandled security issue and someone could be siphoning off your user data without you knowing. Over the years running reinteractive, we have looked at and worked on hundreds of Ruby on Rails applications. The one thing they all have in common without a doubt is that they are built with time constraints which cause (sometimes valid at the time) shortcuts to be taken. These shortcuts can build up as technical debt in a code base and make it harder in the future to maintain and fix.
It is a fairly simple exercise to keep an application up-to-date with the latest versions of code, as long as it is done regularly. It should be done twice a year. If this is left undone for years, the upgrade task to handle all the security issues and bugs can be daunting. We recommend that every Rails application is checked over annually for nine critical points and a report made to action. Your own development team can do this, or you can get reinteractive to do it. We have priced our Rails App Review service so that it is a no brainer to get it done.
The nine points you should get checked are:
1) Setup and Documentation How well documented is your app? How easily can a new developer get up to speed? Is there anything missing in the README on how to get the app set up and started? Is data about where the app is hosted listed and who to ask for to get access? These are critical pieces of information that are always needed in a hurry if anything goes wrong. Keeping this information up-to-date is very important.
2) Automated Tests Do you have sufficient test coverage for your application? The gold standard is 100% test coverage, but few apps reach (or really need to reach) that. The key is that the important parts of your application are tested as much as practical, so that a new developer working on the application can quickly see if the update they just made broke something important.
3) Database Setup Is your database running out of space? It is a recent version? Is it powerful enough? Do you have the correct setup to ensure rapid queries? But most importantly, is there a backup system in place and does it work?
We had a client at Christmas call us (literally on Christmas day) because an offshore developer they hired had run the automated tests against their live database, wiping it entirely. We got access to their app and investigated to try and restore their backup and found that there was none, only one from two months earlier. This client lost all their booking data from two months of their busiest time of year… not a great Christmas present.
4) Performance Are there queries slowing the application down? What sort of time does it take to get into the application? Is there caching being used? Are there opportunities to improve the speed of the application? Per Google: > The bad news is that it still takes about 15 seconds, according to our new analysis. That’s far too slow when you consider that 53% of mobile site visits leave a page that takes longer than three seconds to load. Having a snappy response time on your application can be the difference between gaining that customer and losing them.
5) Security Quite often an application will be running on the same software versions it was built in. This is bad. In fact, fixing this point alone can make all the difference to a critical data breach or your site being shut down. You should be on the most recent major versions of your dependent software libraries and, if this is not possible, you should at least be at the most recent patch versions to ensure critical security updates are done.
6) Versions Along with point 5, getting the most recent versions of code can improve performance and remove bugs. It’s important when you are updating versions of your software and dependent software libraries for the application, to have an automated test suite to make sure that upgrading something doesn’t break the application.
7) Code Quality Code Quality is an area filled with what seems endless opinions, but there are some clear metrics that should be followed for every Ruby on Rails application. Getting these points right can mean the difference between a new developer getting up to speed quickly and producing new features, and one who gets bogged down trying to fix what they are constantly running into.
8) Sensitive Data An application can get sensitive data logged into the code base or stored in the database. You want to make sure that all passwords, API Keys, secret tokens, etc., are stored in the running environment of the application and not in the code base itself.
9) Technical Debt Finally, the points above, if unhandled, become technical debt. Which is defined as: > Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Identifying these issues, if they exist, can help find areas where a bit of time and money spent now can make all future development work roll much faster.
The above nine points are what you can consider to be the minimum we would expect an application to get checked on annually.
You can definitely go ahead and do it yourself with your own team, but if you would like to have an external party to do it, reinteractive can perform it via our Rails App Review service for a low fixed fee.
