Optimizing SOLABS QM Core Software Performance

EQMS - 16 November 2016

By David Abran-Côté, Software Developer, SOLABS

As part of our monthly SOLABS technology blog series, we’re speaking with our developers and analysts on their reflections on the industry, its development and rapid changes, and how their area of current focus may be pertinent to compliance/regulatory and the future of Enterprise Quality Management System (EQMS) software.

This week, we’re talking to one of our developers, David Abran-Côté. David has been at SOLABS for a couple of years now, and originally started coding our streamlined business processes (QM APPs). He recently transitioned to working on the core software itself, SOLABS QM, for the upcoming 10.5 release.

Gordon Bradley [GB]: So how did you get into coding? What’s your background? And how do you find yourself here at SOLABS?

David Abran-Côté [DAC]: I completed a Bachelor of Electrical Engineering degree, and for a while I developed software for the automation of raising livestock. While I was building experience in software development, I decided to specialize and pursue graduate studies in Computer Science. A little while after that, I applied at SOLABS and here I am!

GB: So everyone here who’s a developer, they all share a handful of languages, right? Java, SQL, JavaScript…

DAC: Well yeah, and we’re at different stages of our careers and all have varying degrees of experience, so we overlap quite a bit, but not entirely.

GB: You started at SOLABS writing QM APPs, right? And now you’re writing more of the SOLABS QM core. I’ve spoken with other developers about how the modular nature of code can be a labor-saving device….

DAC: Well, all software is made of building blocks of pre-existing code. No one likes re-inventing the wheel and software engineers are no different. Within that, there’s a whole range of things, from the JavaScript library, jQuery, to us sharing chunks of pre-written, pre-tested code from our QM software with co-workers.

For example, say we have to grab a list of users from a database, filter them, sort them alphabetically and display them in a list—we’ve done this hundreds of times, and it would be a waste to start over every time we had to do this.

But it’s not that it’s simply a labor-saving device: it’s a way of streamlining, optimizing and standardizing the code. It has to be modular, or it’s a sprawling mess, and you’d have varying code all over the place for achieving the same result. Reusing tested code minimizes the occurrences of irregularities, errors and bugs.

GB: So: it’s kind of building on past successes to save time?

DAC: In this way we’re way more productive, as a professional group. We build on the shoulders of all those who came before us. The software community develops tools, and we can all benefit from that.

"I might have to improve the speed of an operation, or make sure that, over time, a system remains efficient... My job is to ensure the system is running as smoothly as possible, to make certain the client isn’t wasting their valuable time."

David Abran-Côté

Software Developer, SOLABS

GB: Your job is in some ways like a detective right? Users of Chrome or Word software may be aware that the applications slow down after a while because of memory leaks, for example. So you find issues similar to this and then concentrate on fixing and optimizing them?

DAC: Yeah, well, it’s not likely to be memory leaks in our case, but yes: I might have to improve the speed of an operation, or make sure that, over time, a system remains efficient. You know: even if we test something with 10,000 processes here, there’s always going to be a client with 50,000 processes. Maybe the code is no longer optimized to support that data flow, or maybe the system has scaled and the code has not. My job is to ensure the system is running as smoothly as possible, to make certain the client isn’t wasting their valuable time.

GB: So not only are you like a detective, but you have to identify the issue, figure out what it’s caused by, then address it? What kind of tools do you use?

DAC: First and foremost, we consult each other. Often one of my co-workers will have solved a similar problem and can provide me with a solution in minutes as opposed to hours.

We also have a number of tools, such as a code profiler, which runs alongside our code as a sort of meter, to show us how system resources are being used. So we run it to find out where the system could be better optimized, and then we concentrate on those areas.

Usually what happens is that a user will notice the problem, we’ll log an issue and reproduce it, and then determine if it’s a browser/hardware/front end/back end issue. It might be performance, for example page loading times. So we have to find out: is it the JavaScript? Or is it the code running on the server that is taking the time?

GB: So the fix could be anything, maybe the module we’re using wasn’t intended for that kind of use, either volume or type?

DAC: Yeah, and until we go deeper into investigation, it’s hard to say what gains can be expected.

For example, suppose it’s an operation that initially takes 15 seconds and we want to make it faster: an 80% performance improvement might be easily achieved on newer code but on the other hand, a 50% gain might be a real challenge on older/more mature code.

For example, a new car model comes out. Version 1 may have more opportunities for improvement than version 10 does–which people will have been poring over, looking for fixes, for 9+ versions.

GB: Cool, so what do you do when you’re not here? And what do you really enjoy more than anything about working at SOLABS?

DAC: Well, I haven’t done as much endurance cycling as I used to this year, but I love that. I just did a 105 km charity ride in one day, so that was both physically and emotionally rewarding.

And at SOLABS, I really enjoy the communication with other developers; I enjoy the experience and intelligence of my co-workers. I love the way we all get exposed to the way other people do the same things. During code review, for example, you can see how using different approaches saves lines of code.

It’s like looking at a painting of the same thing that someone else did: how did they get there? How are their brushstrokes made? What angle are they looking at it from? Do you understand why their way is better, worse, or just entirely different from yours? We work in a tight group of very skilled engineers, and it’s my pleasure to work with these people daily.

GB: Great, so thanks David!