Smartfile: Having confidence in your software
Cleaning up an existing application
- Ruby on Rails
Bauke and Ewout worked on this project
Smartfile is an all-in-1 software package for physiotherapists with a lot of functionalities. For example, users can keep track of their customers, it helps organize patient files, it offers the possibility to manage appointments and it also keeps track of administration. A super tool!
The challenge: seamlessly adding features
Smartfile's software has grown organically. The company started as a start-up and has responded to the wishes of the market. By adding new functionalities every time, they have developed a piece of software that exactly meets the demands and needs of their customers. When Smartfile knocked on our door, their software was fine, but lacked a stable basis. This mainly manifested itself in problems with adding new features.
Why a lack of trust is a problem
The moment an application is unstable, this is at the expense of the trust you have in your own application. If you have to take into account everything that could go wrong, you can no longer code worry-free. If you are going to write a piece of code, and every time you add the code you are afraid that maybe everything could break (or worse that your application will not only break but you will also lose data), then you will never be the fastest to bring things to market. It is often not a question of whether the software will break, but rather when it will break. When the trust in your system is very low, large functionalities can no longer be added. You’ll have to adjust so many things, and take so many things into account (just to ensure that nothing breaks), that you would rather not start on that at all. As a company it isn’t a nice situation if you no longer have confidence in your own software, but for Smartfile that wasn’t even the biggest problem. In their software, their customers work with patient information. If there is even one bug where the customer sees the patient information from another physical therapist, they lose all confidence in your software in one fell swoop. That lack of trust will stagnate the growth of your company. If you already have the feeling that your application is not as stable as you would like, then of course you are not going to roll it out for many customers. That was the biggest problem with Smartfile: there was not a bad piece of software, but there was a lack of confidence in the software and there were good reasons for it. As a result, there was not enough confidence to say: “Let’s grow with this!”
A stable foundation
We started with the foundation of the software. A good example of this is in the field of authorization (what a customer gets to see and what they don’t get to see). By not showing anything by default, and only indicating what a customer is allowed to see, you prevent problems such as leaking patient data. By rewriting the entire foundation of the software, the application has become a lot more stable. Adding new features is no longer a problem and the Smartfile development team can get back to work with confidence.
Every time you add new code, you should test the entire software. That is a time-consuming and intensive job. We have started writing automated tests. For this we had to make an inventory of the current functionalities. If Smartfile programs something new from now on, the server will run all those automated tests for them. This way you know immediately whether your software can handle it and that is good for your confidence in your system. By continuously testing the new code, you always have insight into whether the application still works after you have made adjustments.
Finally, we focused on automating the rollout process. By automating deployment, we have again built in a bit of security and the chance that something breaks in that process is reduced.
What does automatic deployment do
and why do you want it:
When you want to deploy new code, that process usually consists of around 8 steps. You always have to do those steps in the right order and if you forget one, you have a problem. Simply redoing the forgotten step is probably not going to fix this issue. It could just be that if you forgot step six, step seven actually broke something. Then you're going to have an hour of downtime to recover from that. That happens to you once, and after that you no longer have faith in putting things live. So what are you going to do: stop putting things live so often. As a result, your development speed drops enormously. In addition, it also takes a lot of time. You should always check whether the computer has already completed the current step and move on to the next step. It will probably take you half an hour to put things online. The moment you automate this, your software will be online in 10 minutes and you can add extra steps to optimize your deployment. With 'classic' deployment you start in step 1 by turning on the maintenance mode. No one can use the system until you are done. Today, most systems want zero downtime deploys. One way to make that possible is to create a second environment where you will complete all the installation steps. When it's done, quickly flip those two over so the new version goes live. Which also means that you immediately have a roll-back mechanism. So if it's live and you think "oh no, this has gone completely wrong", you can roll everything back with the push of a button as if nothing happened.
Ready for the future
By looking at ways of automation in all areas, we have been able to gain a lot of benefits. As a result, the application is now more stable and adding functionalities is more secure. This way Smartfile can move forward with confidence in the coming years. No matter how many new functionalities they come up with.