Coming from Data Science to Mobile Development and Back

A new point of view on my previous programming experience

I want to share a bit of my story of how my thinking has changed since I started to create mobile. I studied biomedical engineering and bioinformatics, and most classes focused on languages like R, Python, MATLAB and others. So my main programming style was more academic, but after going for mobile development I encountered some problems with understanding how the mobile apps are done.

As many know, during the research phase, you are not obliged to follow as many architectural concepts as in other programming spheres.

Photo by MARIOLA GROBELSKA on Unsplash

I remember the creation of a visual representation of a 3D skull model. I laid down nicely verbose, well-separated code to visualise the whole skull. However, the resulting GUI needed to be more stable and smooth. Later, I removed all the syntax sugar and architecture complexity… it worked flawlessly with the same logic.

There was no problem with the code itself before and after the rework. The mindset behind it was different. Let me explain.

Data science perspective

During the research, people are still determining what will work. Not one person said: This is just an experiment. Or: I will have to rework it in the future. It makes sense that the researcher does not want to spend time searching for the perfect program architecture. The time is invested in the search for answers and solutions to scientific problems.

Another reason the code sometimes looks less verbal is that you are limited by computational power or language limitations. Performance comes at cost of proper architecture sometimes. You can find in code reusing the same variable, which becomes during its life multiple different objects because of transformations. Matrixes can be allocated before the computation starts to get maximum performance. Iterating through numerous vectors of data is considered normal. Mathematical symbols take over the verbose naming of the variables sometimes.

If the idea passes the proof of concept, the actual implementation is usually programmed with the help of skilled programmers to ensure the scalability and robustness of the application.

Photo by Melyna Valle on Unsplash

Mobile developer perspective

Creating the mobile application is an entirely different story. The idea of the app is usually finite. There is no place for speculation. Mobile developers follow one of the prevailing architecture concepts, such as MVVM, MVI and others, which ensure the testability of the app and easy extension of the code. All the models take on one of the immutable states in the stream of states, which comply with the app lifecycle.

Mobile developers are opinionated about handling the architecture. Specific parts are declared by the OS itself, not by the developer. This is the reason why the implementation programmed by the developer is so crucial. The system can behave weirdly because of low battery / other resources, so the developer must expect any situation. Proper state logic, logging, error handling, crash analytics and UI representation of the app are must-haves in a top-notch successful app.

All these uncertainties lead the developers to make their programs robust, easy to maintain due to updates of OS and dependencies, and easily testable.

Photo by Firmbee.com on Unsplash

Why not interconnect the approaches?

I, who was in both of these fields, struggled to understand the right way of developing a product/idea. Programmers usually opt for functional programming or objective-oriented programming. The first brings more control of data, and the second one brings more management of the state. During the development of the product, which is heavily data-oriented and needs to be released among the people, you can go for the golden middle road.

Sometimes, my friends and colleagues point at me that I have the same programming style in every language. The reason is simple. It is easier for me, consistent, readable for anyone and foolproof in any situation.

Modern programming languages support the structures that make it possible to write in any paradigm. So, you can combine the advantages of both of them. Here are some ideas:

• You do not need to use classes. They can slow down the processing. Feel free to use maps and multiple arrays to process the data quickly. (Higher performance)
• Some programming languages support simple classes like structures in Swift, or data classes in Kotlin, so use them to pass the data. (Adaptation of programming language)
• Every function should have the least required data at its disposal. The data should be immutable by design. (Less space for error)
• Separation of state handling and functions. Data are passed to individual well-separated components, which provide modified results/actions/answers and can be used to determine the state. (Separation of means, extendable, testable)
• Extension of data classes can extend the properties of the data, which acts as a separation layer from state handling. (Separation of means/replacement for class-specific functions)

The idea is not to make one or other paradigm less important but to clear out that the world is not binary. These two principles can interweave together to make programming better.

Do not try to change the philosophy of your current project. It is not worth it. It would cause mayhem in the code. Always stick to the philosophy of the established project and improve it by tiny steps. Keep this idea in your pocket. If you encounter a new data-heavy project, you will have one more trick up in your sleeve to toss on the table of ideas.

For me, this paradigm shift cleared out that using the paradigm from my data science / academic type of programming was not wrong during mobile development but different, not expected. Ultimately, always try to be a better programmer.

This brings us to my skull project. I just removed classes and created separate functions where the data were passed. The calculated results were passed to state handling logic. That was the only change. The logic did not change, but how the program was written. It may be a small example, but that was the point where I stumbled across this problem for the first time. Unfortunately, the realisation about what I did back then occurred only now.

This realisation occurred to me during the FOSDEM 2023. It was inspired by the talk “Data-oriented programming in Kotlin” by Ties van de Ven. Thanks for sharing this idea! I recommend checking it.

Here is the link for FOSDEM: fosdem.org

If the video is not available, you can go check it out here at Kotlin Dev Day: