500 million kilometres and zero errors in a project full of challenges

It was one of the most interesting, and most difficult, projects I’ve had the chance to be a part of, Artur told us. And he certainly has something to compare it with, because he has been with MakoLab for twelve years now and, as he himself says, there’s been no time at all for him to get bored.
The project team consisted of several developers, two testers, a project manager and a Scrum Master. Artur outlined their approach to managing the work:
We had to be exceptionally organised because, after the early planning, and with part of the project scheduled to be carried out on the client’s premises, we actually had to work on it remotely. For several months, daily meetings online were essential, along with joint, remote testing. And every sprint ended with a demo.

The operator required the data to arrive on the server within forty seconds of being collected by the application. At the same time, the idea was for the client to have the option of fully configuring the application, in other words, of changing parameters such as the frequency the data is sent on, the size of the packages and the type of data, to name but a very few. Meanwhile, there was to be absolutely no interaction with the user. It was to operate one hundred per cent automatically, turning itself on and off, collecting data, fixing errors and, in addition, checking the quality of the Internet connection and the amount of memory in use.
Arthur offered us some more details:
We had to be certain that our application wouldn’t have any impact whatsoever on a vehicle’s other systems, like its navigation system and the reversing camera, for instance, not to mention the systems that are vital to driver and passenger safety. That was one of the most crucial conditions for the project.
This meant that the team had to determine the potential use of resources from the outset. Artur gave us an insight into what that entailed:
We were analysing the application’s processor and memory usage at every stage of the project. If there were any problems, we introduced the necessary fixes at once.
So, during the preparatory phase, the application was already working in real time to read how much free memory the device had at any given moment, analyse the quality of the Internet connection and, on the basis of that, preparing appropriately sized data packages for sending.
Arthur expanded on the topic for “Insights”:
The architecture of our solution helped us ensure that things worked as they should. We divided the application into independent modules responsible for collecting data, preparing it for sending, sending it, analysing the memory and quality of the Internet connection, configuration and so on. If a problem cropped up, it was easy for us to check which module the error had occurred in.

Options for testing the application were extremely limited, given that the pandemic made it impossible for the MakoLab team to travel to the client’s premises. Artur shared some of his memories of that particular challenge with us:
All we had in the office was one bench [a device for testing an application for in-vehicle multimedia – ed.]. And that, unfortunately, didn’t fully convey the realities of the production environment. So, for instance, someone from the client’s team recorded the application in a car and sat there with a laptop on their knees, while I viewed the logs. And that wasn’t a rare situation at all!
Another challenge sprang form the fact that, while the application is running, a huge number of things are happening. First and foremost, an enormous quantity of data is being collected. Some events appear in the system fifty times per second and, in total, forty event types are being serviced. In addition, it is not always possible for the application to send data to the server, so the information has to be accumulated and sent when an Internet connection appears. If the quality of the connection is poor, then the smaller data packets, as defined by the client, have to be sent first.

Ultimately, the idea was for the application to send data continuously throughout a journey, while anonymising the starting and finishing points. As things turned out, though, the MakoLab team ran into an unexpected obstacle.
Over to Arthur!
That obstacle was the Start&Stop system widely used in vehicles. In the initial stage of the project, every time the engine was turned off, the application treated that as the end of the journey. As a result, particularly in urban environments, what was recorded wasn’t one journey, but ten, for example, depending on how many times the car stood, including at traffic lights, with its engine turned off thanks to Start&Stop. So we had to do some thinking about how to distinguish between the real beginning and end of a journey and momentary stops.
Needless to say, the team found a way round the problem!
We modified the application so that all the information connected with the Start&Stop system would be shown and then we asked the client’s team to install it in some vehicles and make a few journeys. Even though the results weren’t repeatable and differed between vehicles, we succeeded in creating a flexible solution which we then implemented in the production application.
That explanation is Artur’s, of course!
Our application underwent extremely detailed testing on the part of the client. First, it went to the product owner. From there, it moved on to the security department and the team who checked its stability, its effect on the system and other applications and, naturally, its processor and memory use. Finally, it was the turn of the GDPR department, which investigated its compliance with the General Data Protection Regulation.
Artur sums it up like this: We went through it all without any critical fixes.
Keep up the good work!

Artur Ptasiński was talking to Marta Piotrowska