Preventing and reversing technical debt in Bubble.io apps

Photo by Tim Gouw on Unsplash

Context

No immunity

Bubble is an amazing tool. It empowers anyone to build web applications, with a programming background or not.

However, Bubble is “visual programming”, and like all programming — it is all too easy to implement solutions with accidental technical debt.

How Bubble does help — an under-appreciated part of the picture

It is not all bad news however.

Actually, on the balance, it is really really really good news.

As Bubble takes care of all the technical aspects of the platform: servers, versions, frameworks and the like — Bubble profoundly reduces the potential for technical debt.

We’ve heard of entire “traditional code” based solutions requiring a full rebuild because companies like Microsoft discontinue support for old versions of their frameworks/libraries etc. Or Open Source projects becoming dated and everyone moves on to the latest thing.

Not so with Bubble.

Bubble handles all of this. It is a case of one “visual codebase” for all!

And even more exciting when they release native mobile apps in 2024.

So if you hire a dev or an agency, and they present intelligent solutions, and they plan it properly, and they avoid common mistakes — you won’t be put in a position where you need to spend the same money again in 5–7 years to rebuild the solution on the current tech of the day.

BUT…you also play a part in reducing or preventing technical debt

This all being said, you need to take care of what you develop on top of Bubble. There is no special immunity provided by Bubble to poorly organised apps.

Developers and those hiring developers tread with caution. They must:

1. Educate themselves about what technical debt is.
2. Know the common questions to ask themselves or their developer.
3. Contribute positively and collaboratively with their team to make the most sensible decision for the business at that point in time and the future. Product owners whose only priority is to pay the lowest price possible, and blame the developer when something doesn’t go their way, are the kinds of people who create problematic technical debt by their own lack of understanding.

Definition

So lets define technical debt.

Deliberate technical debt

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time — Wikipedia

Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. — ProductPlan.com

These definitions are good. They feature the idea that the professional developer makes a deliberate, business-focused choice.

Examples of deliberate technical debt:

• Simplifying the database structure.
• Choosing simple options for workflows rather than robust ones (e.g. use “send email” action rather than devising a complex notification system).
• Less use of custom events as the workflow logic is deliberately simplified.
• Creating one user role (e.g. account admin) rather than three (e.g. account owner, account admin and account team member).
• Focusing on building the platform for one user type rather than multiple (e.g. focus on buyers rather than buyers, sellers and admins).

Accidental technical debt

There is another kind of debt that is a result of carelessness or not knowing what you don’t know.

Get Will Ericksson’s stories in your inbox

Examples of accidental technical debt we often see in apps built by others, and also in some of the first apps we built (although many of these features are new since we started using Bubble):

• Poor naming conventions
• Incorrect use of UI positioning features such as Container Alignments, Row/Column Gap, Padding, Margin.
• Not thinking with responsiveness in mind.
• Not using styles or style variables to their fullest extent.
• Using static elements not dynamic, e.g. copy and paste.
• Repetition, e.g. writing complex data searches in five places instead of in one place.
• Single page apps with many potentially conflicting “Do on page loads” and “Do whens”.
• Not separating functionality into modules, e.g. pages or reusables.
• Not using custom events like functions.
• Poor organisation of logic

I could go on. But you get the idea.

In some situations, apps with technical debt can take one or more hours to make what should be a two minute change.

If you are in this place, you understand the pain.

Platform technical debt

There is one other category to mention. While being somewhat of a downside of Bubble, this is also true of all programming and is arguably worse in code-based solutions.

This is technical debt causes by major improvements to Bubble platform. Major points at which this has affected us include the implementation of the new responsive design engine, and implementation of the new pricing model.

In both these cases, immediate change was not required. But to continue to build efficiently on Bubble, some reworking of apps was required. For example, we found complex single page apps and heavy use of database triggers to be less desirable under the new pricing model.

Also, once you adapt to the new responsive engine, it improves the situation so much that you never want to go back to the old. But refactoring a page to this new engine can take 2–4hrs to enjoy the benefits.

Learning how to prevent technical debt or use it wisely

Most training options do not address technical debt

Almost all training material online for Bubble I’ve seen is focused on learning the basic or intermediate concepts of the tool. Which is completely fine, for those who are new to Bubble.

They focus on getting it to work. On doing. But not so much on the “why” for option A, B or C.

They don’t usually teach patterns that most software developers learn at university. They usually don’t teach proper technical planning so you measure twice and cut once.

Why students join our training

What we find at Momentum Academy is that students search for and enrol in our 90 day program when:

1. They already have a Bubble app with debt. It may be it self-built, or built-for-them by a freelancer or agency. At a point — usually 6–12 months into the project they realise decisions made early on have introduced reliability issues, make maintenance difficult, and prevent efficient development of new features. After all, Bubble should be fast, right? It is…on the condition you do not have a mess of poorly planned design elements, workflows or data.
2. They want to learn best practice Bubble development from the start. They may want to build an app or change career, and they recognise that moving forward without this knowledge will lead to 12+ months of wasted time learning by making mistakes and relearning. They see the value of starting with the end in mind. Of laying the right foundation.
3. They don’t have access to be part of a professional Bubble development team. Good development teams support each other, review each other’s work, challenge each other, find problems including potential security issues, increase their mutual knowledge, and have an efficiency advantage now and into the future — by working intelligently with technical debt. Because Bubble makes it possible to complete a large project as a solo developer, most Bubble developers and educators have never worked in a larger team for a sustained length of time across multiple projects. This team based experience, on the right team, is the only way to produce a well-rounded developer. Our academy seeks to create this experience which is very difficult to find elsewhere.

Reversing technical debt

“Refactoring” is used to describe the process of recreating the foundations, making adjustments, and generally shoring up the application to allow future maintenance and development to be efficient and fit for purpose.

Our process

Refactoring requires brainstorming, synthesis, problem solving, planning and execution. At Momentum Group Agency, we hold a whiteboard session with our development team. We identify the problems, discuss potential solutions as well as time/cost involved, solve the difficult challenges, and then implement the change. This is not a linear process but requires ideation, challenging of ideas, and accepting the best solutions.

Migrations

Often bulk changes to historic data are needed if data structures are changed. There may be the need to put in place a migration or change plan to ensure that users are not affected, or if this is unavoidable, the app is made not accessible for a few hours while the change is rolled out.

Conclusion

Developers and product owners need to understand technical debt, make informed decisions when taking on technical debt, and know about Bubble development standards in order to avoid accidental technical debt.

Not doing so will result in hundreds or thousands of hours of rework later, at an unacceptably high cost, and may even cause projects to become uncommercial or fail.

Reach out to us at MomentumAcademy.tech if you can relate to this article, and you want to eliminate or prevent technical debt in your Bubble apps.