When Software Turns Into a Swamp: The Natural Evolution of Complex Systems

Why software systems become harder to change over time — and why that doesn’t necessarily mean they were badly built.

A software system can work perfectly well for years and still become increasingly difficult to maintain, extend, and understand.

Adding a seemingly simple feature starts requiring changes across multiple modules. Developers hesitate to touch certain parts of the codebase because the consequences are difficult to predict. A change that once took a day now takes a week, and every release seems to carry a little more risk than the previous one.

Eventually, someone looks at the system and asks the obvious question:

How did this become such a mess? Was it badly designed from the beginning?

Sometimes, the answer is yes. But often, the reality is more interesting — and more difficult to address.

Software doesn’t evolve in a vacuum

When a system is first built, its scope is relatively well understood. The business has a set of requirements, the team designs an architecture around them, and the resulting software reflects a particular understanding of how the business operates.

But businesses don’t stand still.

Users change their expectations. New revenue streams emerge. Regulations introduce new constraints. Integrations with external systems become necessary. Priorities shift, deadlines tighten, and features that once seemed unimportant suddenly become critical.

The software must adapt.

Meanwhile, the original architecture was designed around yesterday’s understanding of the problem. New requirements don’t always fit naturally into existing abstractions, so developers introduce exceptions, add new dependencies, or extend components beyond their original responsibilities.

Individually, these decisions can be entirely reasonable. The alternative might be delaying an important feature, breaking existing behavior, or spending months redesigning a system that the business needs today.

The difficulty is that every decision changes the environment in which future decisions will be made.

Software architecture is not a blueprint that can simply be followed forever. It is a set of assumptions about a business that keeps changing.

The cost of many reasonable decisions

There is another factor: software is rarely built and maintained by one person, following one consistent vision, for its entire lifetime.

Developers join and leave. Teams reorganize. Different people make different trade-offs, often with limited knowledge of the decisions made before them. Documentation becomes outdated, and some of the reasoning behind the original architecture disappears.

Even when everyone involved is competent, maintaining architectural consistency becomes increasingly difficult.

Consider a component originally designed to handle one specific responsibility. Over several years, it acquires additional responsibilities because it is already the most convenient place to implement related functionality.

Other components begin depending on it. Eventually, changing it requires understanding interactions that were never part of its original design.

Nobody necessarily made one catastrophic mistake. Instead, a series of locally sensible decisions gradually produced a globally complicated system.

This is one of the most misleading aspects of software maintenance: a system can become difficult to work with without having been obviously badly engineered at any particular point in its history.

Of course, poor architectural decisions, insufficient testing, excessive coupling, and inadequate technical discipline can accelerate this process. Complexity is not an excuse for bad engineering. But neither is complexity, by itself, proof of it.

Enter the swamp

Imagine walking through a field.

At first, the ground is firm. You know where you’re going, and every step takes you forward. You can change direction easily because the terrain is predictable.

Now imagine that the field gradually becomes a swamp.

The destination hasn’t changed, but moving toward it becomes harder. Each step requires more effort. You need to understand the ground before putting your weight on it. A route that worked yesterday may no longer be the safest one today.

Mature software systems can develop the same characteristics.

The code still runs. The business still depends on it. New features are still being delivered. But the effort required to make each change increases because the relationships between components have become harder to understand and predict.

The problem is no longer just the complexity of individual modules. It is the complexity of their interactions.

A small change can affect an unexpected part of the system. A component cannot easily be replaced because too many other components depend on its behavior. A seemingly isolated improvement requires coordinating changes across multiple teams or services.

The system becomes a swamp: progress is still possible, but increasingly expensive.

And the larger the system becomes, the more costly it is to ignore the problem.

Why adding more architecture doesn’t always help

When a system becomes difficult to maintain, the instinctive response is often to introduce a new architectural pattern, split components into services, or begin planning a complete rewrite.

Sometimes these are the right decisions. Sometimes they make the situation worse.

Microservices, for example, can help isolate responsibilities and allow teams to evolve components independently. But splitting a system into more services also introduces communication overhead, distributed failure modes, deployment complexity, and additional operational work.

If several services are tightly coupled, change together, and exist mainly to call one another, distributing them across a network may simply make the original complexity more expensive.

Conversely, a monolithic application is not inherently a problem. A well-structured monolith can be easier to understand, test, deploy, and modify than a collection of poorly separated services.

The goal is not to adopt a particular architecture. It is to find an architecture that matches the system’s current responsibilities, constraints, and business needs.

That match can change over time.

Realigning the architecture

If a system naturally accumulates complexity as the business evolves, the answer is not to expect its original architecture to remain appropriate forever.

The answer is to periodically realign the architecture with the system as it actually exists.

This doesn’t necessarily mean rebuilding everything. Often, targeted interventions can produce significant improvements.

1. Isolate the parts that are difficult to change.

Some components become deeply embedded in the business and expensive to modify safely. Instead of repeatedly spreading their complexity throughout the codebase, we can isolate them behind a well-defined interface or communication layer.

The rest of the system interacts with that interface rather than depending directly on the component’s internal implementation.

This creates room to improve, replace, or eventually retire the component without requiring the entire system to change with it.

The component may remain complex internally. The important difference is that its complexity becomes contained rather than contagious.

2. Reconsider service boundaries.

A system that has grown into dozens of microservices may no longer benefit from having so many independently deployed units.

If several services have strongly overlapping responsibilities, change together frequently, or require constant coordination, consolidating them into a larger, more cohesive service can reduce network communication, operational overhead, and the cognitive burden of making changes.

This is not a step backward. It is a correction to an architecture that may no longer reflect the system’s actual needs.

3. Restore clear boundaries and responsibilities.

Over time, components often accumulate responsibilities that do not naturally belong together. Carefully separating these responsibilities, reducing unnecessary dependencies, and establishing explicit contracts can make the system easier to reason about.

The objective is not architectural purity. It is to make future changes more predictable and less expensive.

4. Treat architectural improvement as ongoing work.

Architectural realignment is most effective when it is not postponed until the system becomes almost impossible to change.

Regularly identifying the parts of the system where complexity is growing fastest allows teams to make focused improvements before the cost of intervention becomes prohibitive.

This requires engineering judgment, an understanding of business priorities, and the willingness to invest in changes that may not deliver an immediate user-facing feature.

It also requires recognizing that keeping software operational and keeping it easy to evolve are two different achievements.

The goal is not to eliminate complexity

A mature business is inherently more complex than it was when it started. Its software will often reflect that reality.

Trying to force a growing business into an architecture designed for its earliest stage can be just as damaging as allowing the system to evolve without any architectural direction.

Some complexity is essential. Some is the accumulated cost of past decisions. Some comes from requirements that no longer exist but whose implementation remains. And some comes from architectural boundaries that no longer make sense.

The challenge is distinguishing between them.

There is no universal architecture that remains optimal for every system throughout its lifetime. There is no single refactoring technique that can solve every maintenance problem, and no rewrite that guarantees a better outcome.

What matters is understanding where the system is becoming difficult to change, why that difficulty exists, and which architectural adjustments will provide the greatest benefit.

Keep the system moving

Software becoming more complex over time is not, in itself, a failure. It is a natural consequence of software serving a business that continues to evolve.

But complexity left unattended accumulates interest.

Eventually, the system becomes a swamp in which every step requires more effort, more caution, and more resources than before.

The answer is not necessarily to drain the entire swamp and start over. It may be enough to build a few solid paths, isolate the unstable ground, and redirect traffic around the areas that have become too difficult to navigate.

In software terms, that means making deliberate architectural adjustments: introducing boundaries where they are needed, removing them where they no longer help, and reshaping the system to reflect its current reality.

Good software engineering is not about building a system that never becomes complex. It is about preventing that complexity from making the system unnecessarily difficult to change.

At bitGloss, we work with software systems that have evolved over years of real business use. Our focus is not on replacing everything simply because it has become complicated, but on identifying the sources of friction and finding practical ways to make the system easier to maintain, faster to evolve, and better aligned with the business it serves.

Beware of the Title Chasers: How to Spot Power-Seekers in Tech Teams

Every engineering organization has ambitious people, and ambition is healthy. Wanting to grow, lead, or take on more responsibility is a natural part of a career. But there is a different type of person that is worth recognizing early: the one who is not chasing growth, but chasing position.

What the pattern looks like

The title chaser is rarely driven by the work itself. Their energy goes into climbing, not building. Common traits include:

  • Weak craft, strong ambition. Their technical or professional track record is often thin. Instead of deepening their skills, they look for a role where skill matters less than control.
  • Problems are currency. Rather than solving issues, they tend to generate, amplify, or prolong them, because a team in crisis needs someone to “take charge.” A calm, well-functioning project gives them nothing to rescue.
  • Psychological levers instead of arguments. When they cannot win on technical merit, they rely on guilt-tripping, veiled threats, emotional pressure, or making others feel responsible for failures they did not cause.
  • Hierarchy as identity. They constantly signal rank, often through language. Phrases like “back when I was just a lowly frontend developer” or “my devs…” are quiet markers: the first positions the speaker as someone who has risen above the craft, the second frames people as possessions rather than colleagues.
  • Credit upward, blame downward. Successes become personal achievements; failures belong to “the team.”

Why they are dangerous

The damage rarely comes from a single incident. It accumulates.

Toxicity spreads. Teams adopt the behaviors that get rewarded. When manipulation and posturing are tolerated or promoted, others learn that they work.

Similar people gather. Power-seekers tend to surround themselves with people who share their approach, or who are easy to control. Over time, a small circle forms where loyalty matters more than competence.

Good people leave. Skilled, independent professionals are the first to notice the dynamic and the first to walk away, because they can. What remains is a team that is easier to manage but weaker to deliver.

Projects suffer. Decisions are made to protect status rather than to serve the product. Risks get hidden, honest feedback disappears, and technical debt grows because raising problems becomes personally dangerous.

Warning signs to watch for

  1. They are more interested in who owns a decision than in whether it is right.
  2. Conflicts seem to follow them from team to team.
  3. They rely on private conversations, shifting narratives, and selective information.
  4. Feedback is taken as an attack, and critics are quietly sidelined.
  5. Their own technical contributions are hard to point to, yet their influence keeps growing.
  6. They get uncomfortable when others become competent or visible.

No single sign is conclusive. A pattern across several, sustained over time, is.

What to do about it

For individual contributors

  • Document important decisions and agreements in writing. Clarity is hard to manipulate.
  • Do not accept guilt or blame that is not yours. Ask for specifics: what happened, what evidence, what outcome is expected?
  • Build relationships across teams so that you are never dependent on one person’s opinion of you.
  • Know when to leave. No project is worth your professional health.

For managers and leaders

  • Evaluate people on outcomes and on how those outcomes were reached. A “high performer” who leaves a trail of burnt-out colleagues is not a high performer.
  • Pay attention to attrition. Repeated departures from one person’s team are data.
  • Promote based on demonstrated skill and collaboration, not on confidence and self-promotion.
  • Create safe channels where concerns can be raised without retaliation.

For organizations

  • Make technical career paths as rewarding as management paths, so that leadership is a choice for those who want to serve a team, not an escape for those who cannot grow technically.
  • Treat psychological safety as a delivery factor, not a soft perk.

A necessary caution

Not every manager is a power-seeker, and not every difficult colleague is toxic. Leaders who came up through the ranks and mention their past do not automatically fit this pattern. The difference lies in intent and behavior: a healthy leader uses their experience to help others grow, while a title chaser uses it to elevate themselves. Judge by actions, consistently observed, rather than by single phrases or isolated bad days.

Final thought

Great teams are built on trust, competence, and honest communication. Those who chase titles for the sake of power erode all three. Recognizing the pattern early, and refusing to reward it, protects both the people and the products they build.

When the Technology Doesn’t Fit: Rescuing a Platform Buried Under Workarounds

A story from the field, with names changed to protect the innocent.

A few years ago, we were brought in to help a client whose platform had a reliability problem. Almost every week, the site went down, and the cause was usually the same: the database buckled under load. Every new feature took longer to ship than the last, incidents were hard to diagnose, and each new batch of users made things worse.

The root cause wasn’t a weak team or a bad product idea. It was a technology choice made years earlier, and everything that had been built around it ever since.

The setup

The platform had been built from scratch by an independent consultant, whom we’ll call Mark X. He built it on XSpaces, an open-source component framework built on JSF and publicly available. What made the choice unusual is that Mark had written XSpaces himself. Nobody knew the technology better, and for a while the platform did what the client needed.

But a technology can be well crafted and still be the wrong one for the job. This platform needed to grow, and its foundation wasn’t built for that.

What we found

  • The stack was heavy to write, read and maintain. Even simple changes meant navigating layers of component abstractions and configuration, which made the code slow to understand for anyone who hadn’t lived in it for years.
  • The architecture didn’t scale with users. JSF’s server-side component model keeps a lot of state per session, and the way the application interacted with the database put growing pressure on it as concurrency increased.
  • Workarounds were piled on workarounds. Whenever the platform hit the limits of the framework, the answer was a patch. Over the years these patches became load-bearing: some compensated for the framework’s shortcomings, others for the side effects of earlier patches, and some of them added to the very database load that was causing the outages.

The result was a system that fell over almost weekly, where changing one thing risked breaking three others, and where every incident was a firefight rather than a fixable problem.

The human side

This wasn’t purely a technical story. XSpaces was Mark’s own creation, and the platform was built on it, so he was understandably protective. Suggestions to simplify or move away from parts of the stack were often met with resistance, because when the technology is your own work, every critique of it feels personal.

We tried to approach it with empathy. The choices had made sense at the time, and he had kept the platform running for years. But the risk to the client was real: a critical system whose inner workings, and all its accumulated workarounds, lived mostly in one person’s head.

After a few years, Mark moved on, and that’s when the real work began.

Taking over

A handover like this is never clean. Our first priority wasn’t to rewrite anything, but to stop the bleeding and understand what we had.

  1. Reduce the outages. We started with the database: finding the heaviest queries and access patterns, fixing the worst offenders, and adding monitoring so we could see what the platform was really doing under load.
  2. Map and document. We traced the critical flows end to end, separated essential workarounds from historical accidents, and wrote down what had only existed as tribal knowledge.
  3. Add safety nets. We put safeguards in place around the most critical flows, so we could change things without fear.

The phase-out strategy

A full rewrite was tempting, and it would have been the wrong call. The business depended on the platform, and big-bang rewrites have a long record of running late and over budget.

Instead, we designed a gradual phase-out of the JSF-based stack, in the spirit of the strangler fig pattern:

  • New functionality was built on a simpler, more mainstream architecture from day one, so the legacy part stopped growing.
  • Existing modules were migrated one at a time, ordered by business value and pain rather than technical elegance.
  • Workarounds whose reason for existing had disappeared were removed instead of ported over.
  • The overall architecture was simplified, with fewer layers, clearer boundaries and less hidden state, and a much lighter footprint on the database.

Throughout, the platform stayed live and users kept working.

The results

Over time, the platform went from fragile to dependable:

  • Incidents went from almost every week to once every few months.
  • It can handle far more concurrent users, with much more headroom than before.
  • Maintenance is predictable, and new developers get productive much faster on a simpler codebase built on mainstream technology.
  • The client no longer depends on any single person to keep the system running.

What we took away from it

Choose technology for where the product is going, not just where it is today. A stack that works for hundreds of users can quietly become the bottleneck at thousands.

Be wary of niche technology, even when it’s open source. Publishing a framework doesn’t create a community around it. If the only real expert is the person who wrote it, the bus factor is still one.

Recurring incidents are a signal, not a fact of life. If the platform goes down every week, the fix is rarely another patch. It’s usually the architecture.

Workarounds are debt with interest. Each one is cheap to add and expensive to live with, and eventually someone pays the bill.

Migrate incrementally. Evolution beats revolution when the system has to keep running.

Treat the people with respect. Legacy code is never just code. Someone made those choices under real constraints, and the best rescues honor that while still moving forward.

At bitGloss, this is the kind of work we enjoy: stepping into a complicated situation, understanding it before judging it, and leaving the client with a platform that’s simpler, faster and easier to own. If your team is dealing with a system that has become harder to change than to live with, we’d be glad to talk.

Cum a apărut worklog.ro: un tool intern care a devenit produs

La bitGloss nu ne-am propus niciodată să construim un produs doar ca să avem un produs.

worklog.ro a apărut dintr-o nevoie foarte practică: să ne organizăm mai bine munca, să urmărim timpul investit în proiecte și să putem genera rapoarte fără să ne adaptăm permanent după limitările altor aplicații.

Și, ca multe produse bune, a început ca un tool intern.

Problema pe care încercam să o rezolvăm

În teorie, problema era deja rezolvată.

Existau și există multe produse mature pentru time tracking și project management. Am folosit și noi astfel de soluții. JIRA era prezent în ecosistem, iar o perioadă am folosit și YouTrack instalat pe infrastructura proprie.

Dar apăreau constant mici probleme:

  • unele fluxuri de lucru nu se potriveau modului nostru de lucru;
  • raportarea nu era suficient de flexibilă pentru ce aveam nevoie la acel moment;
  • modelul de cost nu era întotdeauna convenabil;
  • trebuia să combinăm mai multe unelte pentru ceva ce, în esență, voiam să fie un proces unitar.

Nimic dramatic.

Doar suficient de multă fricțiune încât să ne întrebăm: dacă tot adaptăm procesele după tool, de ce să nu construim exact ce ne trebuie?

Așa a apărut prima versiune worklog.

Prima versiune: strict pentru noi

Inițial nu exista intenția să devină produs.

Aveam nevoie de ceva simplu:

  • logare de ore;
  • organizare pe proiecte;
  • generare de rapoarte;
  • administrarea accesului pentru echipă.

Frontend-ul inițial a fost construit în ClojureScript.

A funcționat bine și ne-a permis să iterăm rapid. Dar pe măsură ce aplicația a crescut și utilizarea a devenit zilnică, am început să observăm un lucru important: frontend-ul era întreținut de o singură persoană.

În acel context, viteza de dezvoltare conta, dar controlul calității conta și mai mult.

Așa am decis să migrăm frontend-ul către Elm.

Motivul nu a fost „tehnologie nouă” sau dorința de rescriere. Motivul a fost unul foarte pragmatic: Elm mută foarte multe categorii de erori în etapa de compilare. În practică, asta înseamnă mai puține bug-uri care ajung în producție și mai puțin efort de validare manuală.

Pentru o aplicație întreținută eficient de o echipă mică, asta s-a dovedit o alegere foarte bună.

Câțiva ani de utilizare reală

Nu există test mai bun pentru un produs decât să depinzi de el.

Ani la rând am folosit worklog exclusiv intern.

Fiecare neajuns ieșea imediat la suprafață.

Dacă un raport dura prea mult să fie generat, îl simțeam.
Dacă lipsea o funcționalitate, apărea rapid în backlog.
Dacă ceva era greoi, nimeni nu evita problema.

În perioada aceea am trecut prin mai multe iterații și am rafinat produsul continuu.

Momentul în care am renunțat la Excel

Până în 2021, facturarea noastră se făcea încă prin Excel.

Funcționa.

Dar doar în sensul că orice proces manual „funcționează” până când devine suficient de enervant.

Generarea facturilor era repetitivă, predispusă la greșeli și consuma timp inutil.

În 2021 am generat prima factură direct din worklog.

A fost unul dintre momentele în care am realizat că produsul începe să rezolve mai mult decât problema inițială de time tracking.

Pur și simplu era mai simplu.

Legislația a schimbat direcția produsului

Între timp, cadrul fiscal din România s-a schimbat.

A apărut necesitatea integrării cu SPV și e-Factura.

În loc să tratăm asta ca pe încă un tool separat, am ales să integrăm fluxul direct în platformă.

Astfel, worklog a început să lege natural:

ore lucrate → raportare → facturare → transmitere.

Când ne-am dat seama că nu suntem singurii cu problema asta

După ani de utilizare internă, a devenit clar că modelul nostru nu era deloc unic.

Existau mulți oameni și multe firme care funcționau similar:

  • freelanceri;
  • PFA-uri;
  • SRL-uri mici;
  • agenții;
  • echipe care facturează la oră;
  • firme care lucrează atât cu clienți români, cât și internaționali.

Toți aveau nevoie de aceleași lucruri:

  • time tracking;
  • rapoarte;
  • facturare;
  • integrare cu cerințele fiscale;
  • administrare fără complexitatea unei platforme enterprise.

Atunci am decis să deschidem worklog.ro și către exterior.

Nu ca idee de startup.

Ci ca produs validat deja prin ani de utilizare internă.

Funcționalități care au apărut din utilizare reală

Pe parcurs am adăugat funcționalități care au rezolvat probleme concrete:

Integrare GitHub
Posibilitatea de a loga ore pornind de la commit-uri extrase direct din GitHub.

Integrare JIRA
Logarea timpului pornind de la tichetele existente.

Arhitectură multi-tenant
Fiecare cont are:

  • un administrator;
  • unul sau mai mulți utilizatori;
  • proiecte separate.

Administratorul este și el utilizator — poate loga ore ca oricine altcineva — dar are responsabilități suplimentare:

  • generare facturi;
  • management proiecte;
  • management utilizatori;
  • asocieri între utilizatori și proiecte;
  • controlul accesului în diferitele module.

Modelul a fost construit după cum funcționează firme reale, nu după cum arată un demo.

De ce publicăm povestea asta

Există multe produse care promit multe.

Noi preferăm altă abordare.

worklog.ro nu a fost construit pentru a intra pe o piață.

A fost construit pentru că aveam nevoie de el.

Faptul că astăzi este disponibil și pentru alții este doar continuarea firească a unei aplicații pe care am folosit-o ani întregi înainte să o prezentăm public.

Is Your Tech Stack Appropriate or Are You Just Trying to Be Fancy?

When a software project starts struggling, the first instinct is often to blame the code.

But in many cases, the real problem sits one level higher: the architecture and technology choices themselves.

We’ve seen systems built around microservices long before they had enough scale to justify them. We’ve seen multiple frontend frameworks living in the same application. We’ve seen message queues, event buses, service meshes, and orchestration layers solving problems that didn’t actually exist.

The result is predictable: development slows down, debugging becomes harder, onboarding takes longer, and every new feature costs more than it should.

The challenge is that it’s difficult to evaluate an architecture from diagrams and presentations alone.

We Don’t Start With Opinions

Before we assess your technology stack, we need to understand it.

That’s why we don’t begin with a slide deck full of recommendations. We start by working inside your system.

We fix bugs. We implement features. We deal with the same constraints your team deals with every day.

This hands-on involvement gives us a realistic understanding of how your application behaves in production, how your development process works, and where complexity is helping versus hurting.

Only after we’ve worked within your codebase do we form conclusions.

The Questions We Try to Answer

Is your Spring microservices architecture genuinely supporting your scale and organizational needs?

Or would a simpler modular monolith allow your team to move faster?

Are those message queues providing real business value?

Or are they introducing operational complexity that could be replaced by straightforward API communication?

Do you actually need multiple frontend frameworks?

Or are they creating fragmentation, duplicated knowledge, and inconsistent user experiences?

Most importantly:

What complexity is essential, and what complexity is self-inflicted?

An Honest Technical Assessment

After gaining real experience with your system, we’ll give you a straightforward assessment.

If the current architecture makes sense, we’ll tell you.

If parts of it are over-engineered, we’ll explain exactly why.

We’ll identify components that can be consolidated, technologies that can be removed, and areas where complexity can be reduced without sacrificing business capabilities.

Our recommendations are practical and grounded in experience with your codebase—not architectural fashion trends.

Simplicity Is Often a Competitive Advantage

Technology teams rarely suffer because they have too little complexity.

More often, they suffer because complexity accumulates faster than business value.

Every service, framework, integration point, and infrastructure component carries a maintenance cost. Over time, those costs compound.

The best architecture is rarely the most sophisticated one.

It’s the one that solves today’s problems while remaining easy to understand, maintain, and evolve tomorrow.

That’s what we help our clients achieve.

Not more technology.

The right amount of technology.

Every architecture decision has a cost.

If you’d like an honest assessment based on real hands-on work – not diagrams – we’d love to hear about your project.

bitgloss.ro

How We Stopped a Legacy JBoss System from Slowing Down Delivery

At bitGloss, we often work with systems that businesses still depend on heavily, but that very few teams still fully understand.

One common pattern we encounter is enterprise infrastructure that was designed for a very different era of software engineering: large application servers, highly abstracted deployment models, and operational complexity that slowly becomes impossible to justify.

Recently, we helped a client modernize an aging distributed JBoss environment running on AWS.

The Problem: Enterprise Complexity Without Enterprise Benefits

The client’s platform relied on a clustered JBoss architecture that had gradually turned into a maintenance bottleneck.

The environment:

  • Complex XML-based server configuration
  • Custom classloader hierarchies
  • Specialized deployment descriptors
  • Distributed session replication setup
  • Cluster coordination management
  • JBoss-specific operational knowledge

In theory, these application server capabilities offered flexibility and scalability. In practice, most of the advanced enterprise features were barely used.

What remained was mostly operational overhead.

Deployments were slow and fragile. Memory usage was unnecessarily high. Troubleshooting required specialized knowledge that fewer engineers still possess today. Even simple upgrades became risky because the platform depended on behaviors tightly coupled to the JBoss runtime.

The infrastructure had effectively become legacy middleware.

The Real Cost of Legacy Middleware

This is a pattern we see frequently in older enterprise systems.

The issue usually isn’t that the application itself is obsolete. Often, the business logic is still valuable and stable.

The real problem is the operational surface area surrounding it.

Older enterprise stacks tend to accumulate:

  • Vendor-specific deployment models
  • Overengineered runtime abstractions
  • Fragile configuration layers
  • Tooling that fewer engineers understand each year
  • Infrastructure dependencies that slow down delivery

Over time, the organization ends up spending more effort maintaining the platform than improving the product.

The Migration Strategy

Rather than attempting a risky full rewrite, we focused on reducing infrastructure complexity while preserving application behavior.

We migrated the platform from JBoss to lightweight Tomcat instances.

The migration included:

  • Refactoring deployment descriptors to standard servlet specifications
  • Eliminating complex EAR packaging
  • Simplifying deployments to standard WAR artifacts
  • Removing unnecessary application server dependencies
  • Reducing runtime-specific configuration requirements

The goal was not simply “moving servers.”

The goal was operational simplification.

The Outcome

The results were immediate and measurable:

  • Deployment times reduced by 75%
  • Memory footprint reduced by 40%
  • Operational troubleshooting became dramatically simpler
  • Infrastructure became easier to automate and maintain
  • The client was no longer dependent on increasingly rare JBoss expertise

Most importantly, the operations team could stop fighting middleware and focus again on delivering business value.

Legacy Modernization Does Not Always Mean Rewriting Everything

Many organizations assume modernization requires rebuilding entire systems from scratch.

In reality, some of the highest-impact improvements come from simplifying the infrastructure layers around existing applications.

Replacing heavyweight legacy middleware with lightweight, standardized components can significantly reduce operational risk, infrastructure cost, and maintenance burden — without disrupting core business functionality.

That is often where the fastest return on investment exists.

At bitGloss, we specialize in exactly these kinds of legacy modernization projects: untangling complex systems, reducing operational friction, and helping businesses regain control over infrastructure that has become difficult to evolve.

Is Your Website Going Down Right When You Need It Most?

There are few things more damaging to a business than an application that becomes unresponsive exactly when traffic peaks. Not during quiet hours, not in the middle of the night — but during a product launch, a marketing campaign, or the busiest trading period of the year. The timing feels cruel, but it’s not a coincidence. Peak load is precisely when hidden architectural problems surface.

This is the story of one such system, and what was actually causing it to fail.

The architecture that looked fine on paper

The infrastructure in question was built on Azure and, by most measures, looked solid. Redis was in place as a caching layer to reduce database pressure. The database itself was properly indexed. Servers had comfortable headroom on both CPU and memory — no resource exhaustion, no obvious bottlenecks. On a quiet afternoon, everything worked beautifully. Response times sat around 200ms, well within acceptable range.

Then peak traffic would arrive. Response times would climb from 200ms to 2 seconds, then 5, then 10. Eventually the application would stop responding altogether. And then, as traffic subsided, it would recover on its own — as if nothing had happened.

This pattern is particularly disorienting for engineering teams. The system heals itself, so there’s no crash to investigate, no error log with a clear smoking gun. Just a recurring window of failure that’s hard to reproduce and even harder to explain.

Why the obvious suspects weren’t guilty

The natural instinct when an application slows under load is to look at the most visible resources: CPU, memory, database query times. All of them were fine. Redis, the caching layer specifically designed to handle this kind of load, was responding in microseconds. The database wasn’t under unusual pressure. The servers weren’t breaking a sweat.

This is where many investigations stall. If the database is fine, Redis is fine, and the servers have headroom — what’s left?

The answer was in a place most teams don’t think to look: thread pool metrics and connection pool utilization.

The actual problem: threads waiting for nothing

Modern web applications handle concurrent requests using thread pools — a fixed set of worker threads that process incoming requests. When a request comes in, it gets assigned to an available thread. If all threads are busy, the request waits in a queue.

The application was running with default thread pool settings. Those defaults are reasonable for low-to-moderate traffic, but they set a relatively low ceiling on how many threads are available at any given moment. Under normal load, there were always enough threads to go around. Under peak load, every thread was occupied — not doing heavy work, but waiting. Waiting to make a call to Redis. Waiting for a Redis response that would arrive in microseconds.

Here’s the paradox: Redis was fast. The problem wasn’t Redis performance. The problem was that the threads making Redis calls were blocking while they waited, even for those microseconds, and there weren’t enough of them to keep up with the incoming request volume. Requests piled up in the queue. Response times climbed. Eventually the queue filled and the application became unresponsive.

The infrastructure was fine. The bottleneck was a configuration default that nobody had revisited since the system was first deployed.

What the fix looked like

The solution involved three targeted changes, none of which required re-architecting the system.

Thread pool reconfiguration. We analyzed the expected concurrent load and pre-allocated a sufficient number of worker threads to handle peak traffic without queuing. This meant the application could process many more simultaneous requests without threads blocking each other.

Proper connection pooling for Redis. Related to the thread problem was how connections to Redis were being managed. Without a proper connection pool, the application was creating and tearing down Redis connections more frequently than necessary, adding latency and overhead to every cache interaction. A well-configured connection pool meant connections were reused efficiently, and Redis calls became as fast as they should have been all along.

Monitoring for thread pool utilization. Perhaps as importantly as fixing the immediate problem, we added visibility into thread pool metrics going forward. CPU and memory graphs are standard in most monitoring setups. Thread pool saturation almost never is — which is exactly why this problem had gone undetected for so long. If thread pool utilization starts climbing toward its ceiling, the team now knows before users feel it.

The results

Response times stabilized at under 300ms even during peak traffic periods. The infrastructure was able to handle five times the previous concurrent load without degradation. The underlying hardware, the database, and Redis itself didn’t change. Only the configuration did.

What this means for your team

If your application behaves well under normal conditions but degrades or fails under peak load, the problem is almost certainly not the thing you’re measuring most. CPU and memory are easy to monitor, so teams watch them closely. Thread pools, connection pools, and queue depths are harder to instrument, so they go unmonitored — and that’s precisely where these failure modes hide.

Before reaching for more servers or a bigger cache layer, it’s worth asking: do we actually know what’s happening inside our application at the thread level during peak load? In most cases, the answer is no. And in many cases, that’s where the answer is.

Infrastructure problems are rarely about infrastructure. They’re about configuration, visibility, and knowing where to look.

At Bitgloss, we help engineering teams find the real cause of performance failures — not just the obvious suspects. If your application is struggling under load, get in touch.

Is Your Database Slow? Probably Not.

Nine times out of ten, when an engineering team starts complaining about “slow database performance,” the database itself is perfectly fine. The real culprit is almost always hiding somewhere else — in the way queries are written, in how the application accesses data, or in decisions that made sense at the time but were never revisited as the system grew.

This distinction matters more than it might seem. If you assume the database is the problem, you start looking at hardware upgrades, migration to a “faster” database engine, or expensive infrastructure changes. All of that costs time and money — and probably none of it will fix the actual issue.

The symptom everyone misreads

A slow application feels like a slow database. A page that takes five seconds to load, a report that times out, an API endpoint that keeps failing under load — these all point fingers at the database layer. But the database is usually just doing exactly what it was asked to do. The problem is what it was asked to do.

We’ve seen queries that took literal minutes to complete, not because the server was underpowered, but because they were missing proper indexes, performing full table scans on millions of rows, or doing complex joins in the wrong order. In one real case, a reporting query was joining five tables with no indexes on any of the join columns — and then passing the entire result set back to the application to be filtered in code. The database was faithfully returning millions of rows that would eventually be narrowed down to a few hundred. It was working extremely hard to accomplish something that should have been trivial.

What’s actually going wrong

There are a handful of patterns that cause the vast majority of database performance problems:

Missing indexes on join and filter columns. When a query runs a WHERE clause or a JOIN on a column with no index, the database has no choice but to scan the entire table to find matching rows. On a table with a few thousand rows, this is fast enough that nobody notices. On a table with a few million rows, it becomes a bottleneck that grows worse every week as data accumulates.

Filtering in application code instead of in the database. This happens when developers pull a large dataset and then loop through it in the application to find what they need. The database does more work than necessary, more data travels across the network, and the application spends time on logic the database could handle in a fraction of a second.

N+1 query patterns. This is one of the most common and most damaging patterns, especially in applications that use ORMs. Instead of fetching related data in a single query, the application fires one query to get a list of records, then fires a separate query for each record to get its related data. Fetch a list of 200 orders? That’s 201 database queries. At scale, this silently destroys performance.

Joins ordered by convenience rather than efficiency. The order in which tables are joined can dramatically affect how much work the database needs to do. Starting a join with a large, unfiltered table and narrowing down later means the database is carrying a heavy load through most of the operation. Reordering joins so that the most selective conditions are applied early can cut execution time significantly.

What a proper fix looks like

When we analyzed the execution plans on the slow queries described above, the path forward became clear quickly. Execution plans show you exactly how the database is processing a query — which indexes it’s using (or not using), how many rows it’s scanning at each step, and where the time is actually being spent. Most teams never look at them.

The changes we made were not dramatic. We added indexes strategically on the columns used in WHERE clauses and JOIN conditions. We rewrote the join order to match the actual selectivity of each table. We moved filtering logic from application code into proper WHERE clauses. And we replaced N+1 patterns with proper JOINs or batch fetches.

The results were. Queries that previously took two to three minutes now complete in under 100 milliseconds. The database hardware didn’t change. The database engine didn’t change. Only the way the queries were written changed.

What this means for your team

If your application is feeling sluggish and the database is getting the blame, the first step is not to panic and not to reach for the infrastructure budget. The first step is to look at what your application is actually asking the database to do.

Pull the slowest queries from your logs. Look at their execution plans. Check whether the columns you’re filtering and joining on have indexes. Look for N+1 patterns in your ORM queries. These are not exotic problems — they are extremely common, and they are fixable without rewriting your application or migrating to a new database.

The database is rarely the bottleneck. It’s just being asked to do things inefficiently.

At bitGloss, we help engineering teams diagnose and fix exactly these kinds of problems — turning slow, expensive queries into fast, predictable ones without unnecessary infrastructure changes. If your application is struggling with database performance, get in touch.

Making Java code more readable with Type Abstractions

Let’s consider a simple example project, appointments, where each appointment has a date, doctor, patient, and comments. These records are read from input, displayed in list or tabular form and saved. The code involves multiple layers — reading and writing I/O, formatting data, and writing formatted views.

Here’s the actual Java representation of an appointment:

public record Appointment(LocalDate date, String doctor, String patient, String comments) {}

Early in the design, many of the functions that manipulate these appointments had verbose, deeply nested type signatures like BiFunction<List<String>, Supplier<Stream<List<String>>>, String>. While correct, such signatures obscure intent. That’s where type abstractions come in — small, domain-specific type aliases that make the structure of the code clearer and more readable.

The Problem: Overly Complex Function Signatures

Consider this example, which takes a list of headers and a content supplier, producing a string representation of a list view (the table view is omitted for brevity) :

public static BiFunction<List<String>, Supplier<Stream<List<String>>>, String>
listFormat =
    (headers, content) ->
        header(headers).append(data(content)).toString();

This works, but the type signature is long and opaque. It doesn’t immediately tell you what the function is about — only that it’s a BiFunction of lists and streams that returns a string.

The Solution: Creating Semantic Type Aliases

Java doesn’t have native type aliases, but we can emulate them through interfaces that extend existing types. For instance, we can define a View type that captures the concept of a function that takes headers and content, and returns a formatted string:

public interface Types {
    interface View extends BiFunction<
            Collection<String>,
            Supplier<Stream<Collection<String>>>, String> {}
}

With this, our previous function becomes much cleaner:

public static View listFormat = (headers, content) ->
  header(headers).append(data(content)).toString();

The functionality hasn’t changed — but the intent is now explicit. We’ve moved from a generic, mechanical type to a domain-level concept: a View.

Extending the Abstractions

Next, the display function — responsible for rendering appointments — takes a View (the formatter) and returns a ViewWriter<IO> (the executor that writes the formatted output to an IO stream). Originally, its signature was difficult to read:

public static Function<
    BiFunction<List<String>, Supplier<Stream<List<String>>>, String>,
    BiFunction<List<String>, Supplier<Stream<List<String>>>, Consumer<IO>>>

display = ...

Using type abstractions, this becomes far more expressive:

public static Function<View, ViewWriter<IO>> display =
view ->
  (headers, content) -> io ->
    io.print(content.get().count() == 0 ? "No appointments found\n"
      : view.apply(headers, content));

Here’s how the types break down:

  • View — the formatter: takes headers and content, produces a string representation of the table.
  • ViewWriter<W> — the executor: takes headers and content, and produces a side effect by writing the formatted string to a consumer of type W (like IO).
interface ViewWriter<W> extends BiFunction<
        Collection<String>,
        Supplier<Stream<Collection<String>>>,
        Consumer<W>> {}

This separation keeps formatting logic distinct from side-effect logic: View handles what the output looks like, and ViewWriter handles where it goes.

Abstracting Read and Write Operations

Finally, the function responsible for reading a new appointment from input and writing it is defined as:

public static ReadWriter<Appointment, TypedIO> addNew =

    writer ->
      reader ->
        writer.accept(new Appointment(
            reader.readDate("Enter date: ", "invalid date"),
            reader.readString("Enter doctor: ", "").orElse(""),
            reader.readString("Enter patient: ", "").orElse(""),
            reader.readString("Enter comments (if any): ", "").orElse("")));

Its type alias is equally simple and expressive:

interface ReadWriter<R, W> extends Function<Consumer<R>, Consumer<W>> {}

Rather than dealing with nested Function<Consumer<X>, Consumer<Y>> constructs, we now have a ReadWriter — a function that connects two side effects: reading and writing.

The Result

These abstractions don’t change the runtime behavior of the code. They change its shape.
Now, a developer reading Function<View, ViewWriter<IO>> can immediately tell that the function takes a view and returns a view writer — no decoding of generic types required.

The result is clearer, safer, and more expressive code. Type abstractions let us represent not just data, but also intent, in the type system. They make it easier to reason about functions, compose behaviours, and test side effects in isolation — all without adding boilerplate or runtime overhead.

(Adapted from Chapter 3, “Type Abstractions,” in Dr. Software, available at bitgloss.ro/dr-software.pdf

Full example code found here)

Artificial Intelligence: A misleading name for powerful tools

This article is a follow-up of my 2019 article on the same topic, but updated in the light of today’s AI hype.

Like I mentioned then, when I first experimented with neural networks years ago, I was struck by how little “intelligence” there actually was in them. They did exactly what I coded them to do—no more, no less. Today’s systems may look more impressive, but the principle hasn’t changed: these are tools, not minds.

The Problem With the Word “Intelligence”

Humans don’t even have a precise definition of their own intelligence or consciousness. If we can’t define those terms for ourselves, it makes no sense to claim that we’ve created them in machines.

What we can say is that current AI systems don’t exhibit the qualities most people intuitively link with intelligence: self-awareness, understanding, intent, or meaning. They generate outputs by compressing patterns in data, not by reasoning or knowing.

To call that “intelligence” is to confuse statistical mimicry with cognition.

What AI Actually Does

Modern AI systems, especially large language models and generative tools, are best understood as:

• Pattern machines. They excel at finding correlations in vast amounts of data.

• Automation engines. They can handle repetitive, data-heavy tasks quickly and consistently.

• Amplifiers. They extend human capability, but only within boundaries set by training data and design.

This is powerful, but it is not thought.

The 2025 Reality Check

• Scale isn’t sentience. More data and bigger models don’t bring us closer to human-like understanding.

• Usefulness ≠ understanding. A tool can be highly practical without being intelligent.

• The real risks are human. Bias, misuse, privacy abuse—these are problems in how people deploy the systems, not evidence of AI “deciding” anything.

Why the Distinction Matters

If we keep pretending AI is a kind of mind, we risk treating its outputs as if they were grounded in meaning or truth. They aren’t. They’re grounded in probabilities.

AI is not intelligent because we don’t even know what that word would mean in this context. What we do know is that these systems are fundamentally different from human thought: they calculate, predict, and generate—but they do not understand.

Conclusion

The danger isn’t that AI will “wake up.” The danger is that humans will forget what it actually is: computation dressed up in human-like outputs. Powerful, yes. Useful, yes. But never a mind.