In many legacy systems, you can see something I call “Balcony Architecture”. It is not an official pattern, but it describes a real problem I often see in modernization projects.

What Is Balcony Architecture?

Imagine an old building. It is stable, but no one really understands how it was built. One day, someone needs more space and adds a modern balcony to the side. But instead of connecting it properly to the house, they just attach it somehow. It works, but it looks strange. And it is not really safe.

In software, this happens when a developer adds a new feature without touching the existing code. The reason is often simple: the developer does not understand the system or is afraid to change the old code. So they write new code “next to” the system and connect it just enough so it works.

Why Developers Build Balconies

Here are common reasons why developers choose this approach:

  • The code is hard to understand and not well documented
  • There is fear of breaking something when changing existing logic
  • The system has grown over many years and no one knows all the details
  • The team has pressure to deliver new features quickly
  • There is no time or permission to refactor

This leads to a decision: “I will just add this new part on the side. It works for now.”

Signs of Balcony Architecture

You can often recognize balcony code by these symptoms:

  • New code is in separate classes or modules like NewFeatureHelper, FeatureXAdapter, or FeatureYService2
  • The new part repeats logic that already exists, because the developer did not want to change the original version
  • The integration is weak: the new code depends on old code, but the connection is unclear or fragile
  • The old code is treated like a “black box” and never touched
  • Over time, the system grows in strange directions, with many small “balconies” hanging on the side

Example

In an order management system there is price calculation logic and every new pricing rule is added as a new method in a helper class. The class will get many methods like calculatePriceForSpecialCase1(), calculatePriceForBlackFriday(), and so on. No one wants to touch the original logic, so every developer adds one more balcony. In the end, no one will know how the final price was calculated.

Why Balcony Architecture Is Dangerous

At first, this kind of code seems harmless. It solves the problem without touching fragile parts. But over time, it creates big problems:

  • The system becomes harder to maintain
  • Bugs appear because similar logic is duplicated
  • The structure is no longer clear
  • New developers need more time to understand how everything works
  • Technical debt increases with every new feature

What You Can Do Instead

If you notice that you or your team are adding balconies, here are a few steps you can take:

  • Talk about the problem. Give it a name. Once you see it, you can address it.
  • Try to understand the existing code before adding something new.
  • Write tests to protect legacy code before refactoring.
  • Refactor in small steps. Even small improvements help.
  • Pair with other developers when working on difficult parts of the system.
  • Write documentation for areas that are hard to understand.
  • Ask for time and support from the product owner or manager to clean up old parts.

A Positive Culture Change

Balcony Architecture is often a sign of fear. Developers do not feel safe changing the system. A good team culture helps a lot. Teams should feel supported when they want to improve the code and not just deliver features.

Conclusion

Balcony Architecture is a warning sign. It shows that the system has become hard to understand and risky to change. Ignoring this will lead to more complexity and slower progress.

Instead of adding another “balcony”, let’s fix the structure step by step. A solid system is better than one with 20 strange extensions.