iOS developer, Mateusz Chechlinski, is part of smartpatient’s ‘Team Emerald’. Recently, the team saw the opportunity to revamp MyTherapy’s architecture to help speed up the boot time for millions of users. In this interview, Mateusz gives us insight into what was involved, why it is especially crucial to get these details right in healthcare apps, and how a true understanding of Scrum means that developers at smartpatient have a real impact on shaping MyTherapy.

I understand you’ve been working on the architecture of MyTherapy recently to improve boot-up time. Can you tell me a little more about what you’ve been doing and why?
We previously had a modular architecture in the app, which is great, but it turned out to be costly in terms of boot-up time because each module was a dynamic framework. All dynamic frameworks, by default, are loaded at the boot-up time when the app is launched. So, the system has to go through the tree of dependencies and load them. This can be quite costly and takes a lot of time, so it is advised to keep the number of dynamic dependencies below six. With all of the modules we have within MyTherapy and all of the external dependencies, we exceeded that number, so the first thing we decided to do was to switch to static frameworks, which are then merged into bigger dynamic frameworks at a compile time. Effectively, we reduced the number of those dynamic modules to two major ones and several for external dependencies.

The second step was to gather external dependencies in two dynamic modules, which was done by another of our Scrum teams, ‘Team Crimson’. Thanks to that, we now only have four such modules (two for our own code and two for external dependencies) plus partner programs. Partner programs are modules that regular MyTherapy users don’t see but are there for users of the specific patient offerings we develop for our partners. We decided to stop loading partner programs at launch but only when they are needed. Typical users use only one partner program if any, so there is no need to load them all. We decided not to load them at all until we know that a user uses a certain program. Thanks to that, we don’t need to worry about how many partner programs we have.

In the end, we have cut boot time by more than half.

From a technical perspective, what were some of the key considerations in the process?
It’s tricky to discuss in detail without sharing source code! But it is worth mentioning that for loading partner programs in the runtime, we use the ‘dlopen’ function, which is slower than loading at the boot time normally performed by the operating system, but the gain comes from the fact that we load only one framework, if any, rather than loading all of them. This is where the optimization comes from. It requires some additional focus on bug prevention because you can run into a situation where you expect a given module to be loaded in the memory and it’s not. To make it work, we introduced a Partner Program Provider, which is a special class that ensures that every partner program is loaded at the time it is needed.

You mentioned that the benefit of the new architecture increases with each additional partner program module that’s added as they no longer slow down boot time. So, it seems to be a good future-proofing strategy, as well. How well prepared are we now for the addition of any potential new partner programs?
With the architecture as it is now, it is definitely easier to introduce another partner program to our app. We have a whole framework for features that can easily be adapted for typical uses, and for more special cases we’re ready to quickly adapt. I think at this point we have pretty much everything covered! Maybe I’m exaggerating, but at this point, we have a wide range of potential use cases already covered, so I think it makes it really easy and quick to start working with us. Especially if the alternative is to create your own app from scratch and trying to get to the point we’re at now with MyTherapy. And the architecture is now better equipped to handle more partner programs without compromising performance.

Was there a lot of refactoring required throughout the process?
It required some refactoring, and this is something that is frequently addressed throughout the development process of MyTherapy and partner programs. As we increase in size and our userbase increases, it is something that needs regular attention, and you need this process to make sure the architecture is functioning as well as possible. Fortunately, we have a very democratic organization within our company, and this means that we can, early on, detect potential changes and we can adapt to them. So, we do perform refactoring regularly whenever we discover something that will help us in the future.

Without doing so, we would soon start to build up “technical debt” that would be more difficult and time-consuming to solve in the future.

Not all companies give developers the freedom to work on the, let’s say, less “glamorous” side of things. Why is it so crucial to work on aspects such as the architecture as well as more user-facing features?
Yeah, it true. Even today, many companies have a monolithic architecture for their apps, which means it’s one big module. That makes developers’ lives more difficult by increasing compile time, making big changes more costly and increasing chances of a “spaghetti code”. There are also companies that, as you mentioned, focus on delivering things that are more visible for the user. It’s tricky and it’s a trap that is easy to fall into because, in reality, users do notice things like boot-up time. It might not be as direct but if you have an app that you open daily, as many people do with MyTherapy, it gets annoying if you have to wait every time you start it. So, while improving boot-up time might not have much of a “wow” factor, it matters to users.

I imagine this is particularly important given the nature of MyTherapy, right?
Exactly. If you use an app every day those small details gain more weight. If there’s a detail that annoys you in an app you use now and then, okay, you can live with it. But if you use the app three or four times a day, maybe even more, then this detail is more important to you. As well as reducing boot-up time, we’ve also been focusing on improving our UI and UX designs and improving accessibility. For example, by adding special patterns for people with color blindness. It’s the sort of thing that most people won’t notice but will be important for some. Imagine you’re having eye treatment and you can hardly read what’s on the screen because it’s not adaptive! So, it is really important.

If we don’t get these details right, then people will stop using the app. And because MyTherapy and partner programs are so closely linked to people’s medications and treatment, we have a responsibility to work on getting them right.

For an app that's so important to so many people, we need to aim to make MyTherapy class-leading in every respect.

Working with Scrum as we do here, how much responsibility and influence does the team have in deciding to improve aspects such as architecture?
Many companies work with Scrum or, rather, work with what they call Scrum. In my experience, hardly any get the concept of Scrum right because one of the core ideas behind it is to give the team more independence and power to shape the app. Here at smartpatient, there is a real understanding of Scrum, and thanks to that we can feel as though we have a real impact on the app. At any point, we can express our opinions and they are seriously considered because the decisions are made by the team itself rather than by the higher management.

I think it has a positive impact on the quality of MyTherapy and partner products. We have many great engineers, software developers, designers, who are very good at their job. In companies where management gets too heavily involved, telling you how this or that should be done, can have a negative impact. If we have the responsibility, it has a positive impact on quality and user experience, while also meaning we can immediately address issues, fix any problems that crop up, and make improvements without needing to go through lengthy processes.

Given the level of input the team has in shaping the development of MyTherapy, do you feel as though that adds a little something extra in terms of satisfaction when you see the app performing well and helping people?
Yeah, definitely. What matters the most to me is the fact that I can feel as though I have an impact on the app. I believe it matters for many developers.

It’s not just a job where you earn some money, you’re doing something that matters. You want to be a part of something bigger and feel as though you have a real impact. Without that feeling of personal involvement, you can feel as though you’re just another cog in a machine.

Absolutely. In a previous interview on the blog, Florian [Head of Product Owners] said that working on a single product rather than jumping from project-to-project also added to that feeling of making an impact. What are your thoughts on that?
Honestly, I think it’s a matter of personal preference. Jumping from one project to the next can also be fun! However, if you work on a single product, you can really commit to it and you can see it growing over time. It becomes your baby, right? You see how it changes over time and how it becomes better and more appreciated by users. It gives a sense of commitment.

I think that this, along with a real understanding of Scrum and the responsibility the team has for shaping the development of MyTherapy, makes smartpatient a really interesting place to work for developers.

We are hiring!
Are you interested in helping develop a multi-million user app and developing products used by companies such as Bayer, Novartis, and Merck? Check out our job listings here: Careers.