Skip to main content

Application Architecture - Speed vs Scalability

· 13 min read
Bruno Carneiro
Bruno Carneiro
Fundador da @TautornTech

Application design is an extremely important topic in software development. I see many people with no idea how to create a good architecture, which can create major complications as the system evolves — new features, new demands, problems, delivery pressure, and many other factors that contribute to increasing application complexity.

Entire systems can be rebuilt simply because the team failed to create a good architecture, or at least an ideal starting point that allows the project to evolve and adapt. This can happen for various reasons: lack of knowledge and pressure to deliver (very common). The latter creates a trap by assuming that skipping precious software development steps in the name of speed and delivery won't affect quality and scale.

In this article I'll cover some problems that can arise from not following a well-defined standard. My goal is to bring the software developer's perspective and things they should care about to mitigate future problems — for themselves and for the company.

warning

⚠️ This article is not a personal criticism. I myself have made many of these mistakes. The idea here is to share lessons I've accumulated along the journey, to help other devs avoid common pitfalls.


Traps of bad architecture design - Speed vs Design​

Before talking about how I develop an architecture, I'll cover the traps that a lack of good software design can bring to your application. Some things here can be corroborated by the book Clean Architecture by Robert C. Martin (Uncle Bob), where the author talks in the first chapter about costs that increase due to poor architecture.

I've been working in software development for over 10 years and along my journey I've seen many things. I've worked on everything from small back-office systems to large E-commerce, Telecommunications, Banking, Financial, and LLM companies — many with millions of daily transactions — and surprisingly they all had common problems: the false sense of speed in software delivery.

I won't get into the merits of agile development. Nowadays topics like Kanban, Scrum, hybrids of both, and various other development methodologies for miraculously delivering software are more common than ever. From the 1970s to today, software development has gone through various changes and methods to facilitate the control of software creation, iterations, testing, and delivery. But where does the code actually come in, and why is it so easy to skip precious development steps just to fit deadlines? The reasons are many — from lack of team maturity to tight deadlines with Stakeholders expecting miracles (the most common). The latter can even happen due to a lack of negotiation skills.

Negotiation​

Negotiating deadlines isn't always easy, and people often assume all software is the same — if you built one page, every single page will take the same amount of time. Right? But it's not quite like that. Each company has its own business rules, client niches, development team expertise, company culture... All of this influences the final delivery. But a very important point here is that the developer needs to know how to NEGOTIATE. That's right — it's crucial to learn how to negotiate any delivery. Tight deadlines can create a cascade effect on deliveries, generating technical debt, increased cost for a new release, team exhaustion, and so on.

Of course, many costs are invisible and making fast deliveries can even seem like things are going well. But not always.

Who here has never disabled (or never created) a test pipeline just to deliver something? I've done that many times. I'm not proud of it, but it was necessary to meet some crazy deadline. At first it might seem faster, but down the road the technical debt comes calling. Production problems will arise and more time and resources will be spent to solve a given problem.

Of course it varies a lot from delivery to delivery — some code shouldn't even exist, but we're improving it, hehehe.

My point here is to know how to negotiate, to inform that a certain deadline may not be met, JUSTIFYING that, of course. Nothing is worse than saying something won't be delivered without a good argument. It's bad for you, for your team, and for the company. This can demonstrate a lack of clarity about the problem/challenge you're facing. There are deliveries where we genuinely don't know the deadline, but a justification exists — for example: "learning a new technology." It's normal to ask for time for that (being open-ended will only cause the time curve to increase; human beings will always fill all the time given to them — Parkinson's Law), and it may be that the deadline wasn't enough. In that case, a justification is warranted — nothing more.

I understand that many deadlines are tight. I've worked on many projects late at night, pulling all-nighters to meet demand. Many times it's outside our scope to defend needing more time — people higher up in the company hierarchy may have already sold a deadline of X and that's that. I love joking during plannings when a PM/PO asks for a deadline to deliver something: "you can pick any timeline you want, as long as it's done by such-and-such date, hehehe." It's sad but true.

But if the deadline is often top-down, where does negotiation come in? Here it's important for establishing boundaries and expectations. Even if my client/business owner/manager dreams of an unrealistic deadline, they must be very aware of it. I negotiate that. It won't always be easy and many won't be happy with the answer, but it's better to be clear and direct than to commit to something that isn't possible.

Many times, developing something with architecture X, technology Y, and N functionalities can take longer — so negotiate something different that can be delivered and satisfy a given demand. It may be that you need to buy time for a larger feature. This is very valuable and I've done it many times. You know that simpler delivery you'll improve later? Well, it goes to production, solves the problem, and we move on.

This can be important in some cases — for startups, validating a product, MVP, quick test, or whatever — but caution is needed so it doesn't become the standard. Remember, fast and poorly done deliveries can generate a huge headache. Poorly designed systems tend to look beautiful and robust at first, but when you need to scale them you'll see you built a house of straw that will collapse at the first gust of wind.

The world isn't a bed of roses, but try your best to negotiate realistic deadlines, realistic deliveries that can satisfy both sides. This is a crucial skill for career growth and one that is often not understood or developed.

💡 It's easy to build systems. The hard part is building something that scales.

Impacts of code that doesn't scale​

As I mentioned before, fragile code can generate future problems. It's not just me saying this — the software industry agrees. Here are some points that fragile code can cause:

  • Reduces maintainability and scale: fragile code tends to be hard to change, understand, and evolve. Nothing is worse than opening a page with no tests, with thousands of meaningless lines, that is in production doing something only God knows how. Any change is always a headache and bugs come along with it;
  • Considerable increase in bugs and technical debt: "Let's ship it like this, we'll fix it later" — Myth. We'll never fix it; we'll be consumed by another amazing feature that must be delivered on a crazy deadline. More bugs will be created, technical debt will keep growing, until the day someone says in a planning meeting: "we're going to have to refactor everything." And there goes time and money into the void;
  • Decreases productivity and efficiency: Developers spend considerable time just reading code, whether it's good code or fragile code — that's a fact. Of course, fragile code greatly increases reading and comprehension time, which considerably reduces productivity. As a result, the time to develop something starts to drop and small features take longer, making the code increasingly difficult to work with, and people are even afraid to deploy something.
  • Increases cost and risk: This one is rarely talked about because it's sometimes not very clear to the engineering team, nor is it conveyed with much clarity. But there are "invisible" costs in software development — the impact that fragile code has on the system. Bug fixing, rework, maintenance, system stability, security, side effects, trust, and so on.

Here's a chart of the software lifecycle and the increasing cost of delivering small new features:

Reference: https://diego-pacheco.blogspot.com/2020/06/software-architecture-hidden-costs.html

As you can see, changes at the beginning are easier and cheaper; over time this becomes more expensive and more difficult. Now imagine this with code that isn't well crafted — it only gets worse.

Lost opportunity from rising costs​

When the cost of maintaining and evolving the system begins to grow uncontrollably, a direct consequence is the loss of opportunity to innovate. Projects that could be put into production quickly end up being swallowed by technical problems, constant refactoring, unexpected bugs, and low predictability.

The time that should be used to deliver value to the business is being used to "fight fires." And this, in the long run, causes companies to lose market share, delay strategic launches, and miss out on trends.

With every sprint blocked by architectural problems, a market opportunity may be slipping away.

Why does the cost of code increase?​

The cost of code increases due to a series of cumulative factors, many of them invisible in the short term:

  • Accidental complexity: the solution becomes more complicated than necessary.
  • High coupling between modules: any change creates unexpected side effects.
  • Lack of automated tests: the team loses confidence when making changes.
  • Constant rework: poorly implemented features come back to the workbench.
  • Team turnover: without a clear architecture, the ramp-up of new devs is slow.

In addition, there is a well-known phenomenon called the "cost of change": the more time passes, the more expensive it is to change what has already been built. This is well illustrated in the software lifecycle chart.

Ways to prevent the curve from growing​

Preventing the cost curve from growing exponentially involves good technical practices, team alignment, and execution discipline. Some key actions:

  • Define a good architecture from the start, even if it's simple. Evolving something well-structured is easier than refactoring chaos.
  • Have a minimum coverage of automated tests (unit and integration). This ensures confidence in changes.
  • Organize your project into domains or features, separating responsibilities (e.g., Feature Sliced Design, DDD, Modularity).
  • Document the bare minimum: a good README, a standardized structure, and pull request patterns already help a great deal.
  • Reinforce review rituals (code review, pair programming) with a focus on clarity and best practices.

The idea isn't to rigidly constrain development, but rather to create a solid foundation that facilitates the growth of the application and the team.

How to mitigate the impact of fragile code​

If the system already has a fragile foundation, it's still possible to correct course — even if gradually. Some strategies:

  • Progressive refactoring: whenever you're changing a module or creating a new feature, take the opportunity to improve the surrounding code.
  • Tests as a shield: before touching critical parts, write tests that describe the current behavior. This protects you against side effects.
  • Map the most critical points: identify the files/pieces of code that generate the most bugs or rework and prioritize refactoring them.
  • Share knowledge within the team: document architectural decisions and explain the importance of adopted patterns.
  • Create development guidelines: help the team understand what "good code" looks like within the company's context.

Remember: you don't have to fix everything at once. But you need to start.

Conclusion​

Martin Fowler argues that software architecture is more about decisions that are hard to change than about diagrams. That's why it's essential to define early on what will be considered the core of the application and what can be adaptable.

According to the Consortium for IT Software Quality (CISQ) report, poor software quality cost the US $2.41 trillion in 2022. And according to the Standish Group's CHAOS Report, only 31% of software projects are delivered on time and within budget — with bad code being one of the main contributing factors.

Reference: https://www.sonarsource.com/blog/the-true-cost-of-bad-code-in-software-development/

Building software is a marathon, not a 100-meter sprint. The architecture you define today will be the ground your team walks on tomorrow. Take good care of that terrain.

Invest in best practices from the start, negotiate deadlines intelligently, avoid dangerous shortcuts, and think of scalability as a strategic piece of your product. And remember: not all code is urgent, but all poorly crafted code eventually comes due.

info

📐 Good architecture is invisible to the user, but vital to the development team.

If you found yourself in some of the scenarios I described, know that you're not alone. Growing as a developer is exactly this: recognizing, adjusting, and continuing to evolve.

There are other points that can lead to poorly designed projects, such as poorly written or thought-out tasks. But that's a topic for another article — I wanted to bring the software developer's perspective here.

tip

I have other articles related to software architecture and delivery:

References:​