We are in the second version of the system, which was released at the end of 2021.
The first version ran in tests and in the classroom between 2019 and early 2020, when it was discontinued to make way for the current version, 2.0.
Since then, we've been dedicated to launching new features and content, and we've experienced an exponential growth of our community, reaching thousands of users.
This competing demand among so many accesses put pressure on the product's internal flows, leading to scenarios of overload, instability, and even episodes of short unavailability.
It's hard to do the simple
In early May 2023, we released version 2.20.00, with features that boosted the platform's speed and stability.
Developing an application that is fast, simple, and accessible is an ambitious goal, especially in an environment where maps and databases intersect.
At Mapfry, we face these challenges on a daily basis as we work to create efficient Geomarketing solutions.
The inevitable degradation of design
Software is complex and tends to get more complex over time.
Each modification risks introducing complexities that hinder future changes.
We call this degradation, the result of small implementations that add new rules, filters, conditions, “if this, then that, but with the exception of this”.
As these rules add up into a loosely cohesive set, we have a small tower of babel where even the developers get lost.
Limitless complexity
In any system, complexity tends to grow indefinitely.
Each new developer brings their own skills and preferences, each component asks for a specific approach, which leads to a fragmented and difficult to manage code base.
We recognize that software complexity is an inevitable reality, but we believe that with discipline, communication, and an approach focused on simplicity, we can create an application that is truly fast, simple, and accessible.
The limit of complexity
In order to avoid these scenarios, from time to time, we have to go back to the drawing board and rethink the entire system and how it will evolve.
This is a huge job that does not generate new revenues, the changes take place behind the scenes and, if everything works out, they will be little noticed.
That's why we are faced with companies with great financial success running problematic systems, full of bugs and crossed paths.
Nothing more natural for a company to make decisions that lead to more sales at the expense of large scale maintenance.
Someone from the board may say:
We need to move on to new features.
We don't have the luxury of looking back.
Companies exist to make money.
It turns out that, over time, this problem accumulates, in a process called “technical debt”.
Technical debt is when developers make the decision to simplify some components to deliver the product earlier, even though this may compromise their productivity in the future.
The interesting thing about the expression “debt” is that it charges interest, the more time that goes unresolved, the greater the consequences, since new parts of the system are being added to a problematic whole.
While developers and product professionals hate to live with such consequences, the company as a whole sees no problem leaving things at that.
Until the sum of all the debts presents itself as a bigger problem and threatens the company's very existence.
This may come from a critical bug, from the impossibility of updating some part of the code, or from a more current competing solution, which is born debt-free.
In this scenario, the complexity limit is extrapolated and all decisions taken for the benefit of financial results are reevaluated.
Maybe it's late, maybe there's still hope, but even then, the company will have to dedicate enormous efforts to making its current product work, losing evolutionary speed.
Product companies, such as Mapfry, understand that it is up to them to define an acceptable limit for complexity.
For this reason, we continuously work to mitigate the effects of degradation, carrying out rigorous code reviews that are always ready to face new reconstruction journeys.
Keeping the code clean and modular is essential so that we can continue to innovate without compromising the initial objectives of speed, simplicity, and accessibility.
System architecture
Just as modernist buildings combine several purposes, a good system must allow the harmonious coexistence of its components.
Simplicity in interfaces is key to attracting and delighting our users, so we focus on creating APIs and modules that are intuitive and elegant.