Monday Myth: "Our Application Is Complex"

The Comfortable Explanation

Every generation believes it stands at the summit of complexity. Ours happens to express that belief through software. Spend enough time in enterprise IT and you will eventually hear someone explain a missed deadline, an operational failure or an architectural dead end with the same resigned conclusion: our application is simply too complex.

The explanation rarely attracts scrutiny. Complexity has become a badge of honour, almost a mark of technical sophistication. The larger the architecture diagram, the more understandable the delays appear. Somewhere along the way software stopped treating complexity as an engineering problem and started presenting it as an achievement. Complexity no longer demands reduction. It merely demands acceptance.

The claim deserves investigation because no other mature engineering discipline treats complexity in quite this way.

Reality Already Operates at a Different Scale

At this very moment reusable launch vehicles leave Earth's atmosphere, separate at hypersonic speed, navigate through the vacuum of space, reignite their engines and land autonomously on floating platforms before flying again. Commercial aircraft cross continents while air traffic controllers continuously calculate safe separation between thousands of aircraft. Modern MRI scanners reconstruct three-dimensional images from minute magnetic disturbances inside the human body. Semiconductor manufacturers repeatedly position structures measured in nanometres while surgeons routinely replace organs that evolution spent millions of years refining.

None of these systems enjoys forgiving operating conditions. Physics negotiates with nobody. Materials fatigue. Weather changes. Components fail. Human beings make mistakes. The consequences frequently involve lives rather than customer satisfaction scores.

Yet aerospace engineers rarely conclude a post-mortem by saying that rockets are complicated. Civil engineers do not excuse collapsing bridges because structural mechanics proved difficult. Cardiac surgeons do not justify poor outcomes by reminding patients that biology remains astonishingly complex. Every one of these professions accepts complexity as the starting point of engineering rather than its conclusion.

They understand a distinction that software organisations increasingly overlook.

Reality often demands complexity. Poor engineering produces complication. Those two ideas rarely describe the same thing.

Engineering Has Always Removed Complexity

History remembers engineers who simplified the world, not those who complicated it. Brunel reduced the friction of transport. The Wright brothers reduced the impossibility of controlled flight. Toyota reduced waste inside manufacturing. SpaceX reduced the cost of reaching orbit by making rockets fly again. None of these achievements eliminated complexity. They disciplined it until ordinary people no longer needed to notice it.

No mature engineering discipline seeks admiration through complexity. Bridges do not become masterpieces because they contain the largest possible number of beams. Jet engines do not improve by accumulating additional moving parts. Watchmakers do not compete to insert unnecessary gears merely to impress other watchmakers. Every additional component introduces another inspection, another maintenance procedure, another failure mode and another opportunity for reality to intervene.

Progress therefore removes complexity whenever reality permits.

Software frequently rewards the opposite behaviour.

Architecture diagrams expand into sprawling constellations of microservices, service meshes, orchestration engines, event buses, gateways and integration layers. Every additional box appears to demonstrate architectural maturity. Every new abstraction promises future flexibility while quietly introducing another dependency that someone else must understand five years later.

Imagine presenting a mechanical gearbox containing three times the required number of gears because it demonstrates technical sophistication. No serious engineer would admire the drawing. They would simply ask why the gearbox required so many gears in the first place.

Software asks that question surprisingly rarely.

Complexity Never Disappears

Engineering never eliminates complexity. It merely decides where complexity should live.

Every bridge transfers structural complexity away from the traveller and into steel, concrete and mathematics. Every aircraft transfers aerodynamic complexity away from the passenger and into decades of engineering discipline. Every medical device hides extraordinary biological understanding behind interfaces simple enough to use during moments of extreme stress.

Successful engineering therefore follows a remarkably consistent principle. Complexity remains inside the system while simplicity appears at the point of use.

Enterprise software occasionally reverses that relationship.

Customers encounter workflows instead of outcomes. Configuration replaces intuition. Documentation replaces discoverability. Training replaces usability. The organisation has not removed complexity.

It has outsourced it.

Complexity Compounds

Software possesses a characteristic that engineers often underestimate. Complexity rarely grows linearly.

Adding one service does not merely create another repository. It creates another deployment pipeline, another monitoring dashboard, another ownership boundary, another security surface, another compatibility matrix, another operational procedure and another collection of interactions with everything already in existence. Every component increases the number of possible relationships. The architecture therefore grows geometrically rather than arithmetically.

This explains why companies such as SpaceX relentlessly remove parts instead of celebrating them. Every eliminated valve removes maintenance, inspection, manufacturing, logistics, inventory, testing and potential failure. The engineering principle sounds deceptively simple.

The best part is no part.

Software too often celebrates the opposite instinct.

Complexity Has Mass

Every unnecessary service requires deployment, monitoring, upgrades and support. Every additional interface extends testing. Every dependency increases coordination. Every abstraction lengthens diagnosis. Every approval introduces waiting time. None of these activities produces customer value. They merely increase the effort required before value can emerge.

Complexity behaves remarkably like physical mass. Every dependency, approval, service boundary or abstraction increases the effort required to change direction. Acceleration becomes progressively more expensive until movement itself starts looking risky. Organisations rarely notice the transition because inertia arrives gradually. Eventually they mistake the absence of movement for stability while competitors simply continue travelling.

The financial consequences appear long before anyone recognises them. Lead time increases. Time-to-market slips. Engineers spend progressively more effort understanding yesterday's decisions instead of delivering tomorrow's capabilities. Features arrive after competitors have already learned from the market. Revenue rarely waits for architectural elegance because markets reward organisations capable of learning faster than everyone else.

Complexity therefore carries a business cost long before it becomes a technical concern.

Dead Capital

Economists distinguish between productive investment and dead capital. Productive investment creates future returns. Dead capital consumes resources while producing little additional value.

Complexity behaves remarkably like dead capital.

Every unnecessary abstraction, feature, service, governance process or approval workflow absorbs engineering capacity that could otherwise improve reliability, shorten feedback loops or solve a customer's actual problem. Organisations rarely recognise the expenditure because it arrives disguised as engineering effort rather than financial loss. The opportunity cost nevertheless compounds every sprint. Engineering budgets gradually finance maintenance instead of progress, coordination instead of innovation and prediction instead of discovery.

The balance sheet never contains a line labelled Architectural Complexity, yet the organisation pays the interest every single day.

Thinking on Behalf of the Customer

Complexity rarely arrives wearing a villain's cloak. More often it enters through good intentions. Another workflow might help somebody one day. Another abstraction might improve flexibility. Another configuration option might satisfy an edge case. Another feature might anticipate tomorrow's demand.

Eventually organisations begin believing they can think on behalf of the customer.

The phrase sounds admirable until examined more carefully.

Railways do not decide where passengers should travel. Roads do not determine destinations. Electricity does not choose which appliances deserve power. Infrastructure succeeds precisely because it avoids making decisions that belong to its users.

Enterprise software increasingly attempts the opposite.

Instead of observing behaviour, organisations speculate about behaviour. Instead of shortening feedback loops, they lengthen requirement documents. Instead of learning from customers, they attempt to outguess them. Every incorrect prediction eventually becomes another feature, another configuration option, another workflow and another branch of code that somebody must maintain indefinitely.

The result rarely resembles customer-centricity. It resembles engineering speculation funded by customer money.

Conway Never Left the Room

The deeper irony lies elsewhere. Much of what software teams describe as technical complexity has remarkably little to do with computation itself. Conway observed decades ago that organisations design systems mirroring their communication structures. Every departmental boundary becomes another API. Every reporting line becomes another service. Every governance committee creates another workflow. Every approval process eventually materialises somewhere inside the code.

Applications gradually stop modelling reality. They begin modelling the organisation that produced them.

What later appears as technical complexity often started as organisational complexity. The software merely fossilised it.

Complexity as Status

History offers an interesting contrast.

The greatest engineers rarely became famous for producing the most complicated machines. They became famous for making extraordinarily difficult problems appear almost obvious. Elegance became the ultimate demonstration of mastery because only genuine understanding permits reduction.

Enterprise software occasionally celebrates the opposite instinct.

Complexity itself begins signalling competence. Architecture diagrams grow larger. Technology stacks become longer. Dependency graphs become denser. Difficulty quietly transforms into status. Once complexity starts demonstrating expertise rather than failure, organisations stop trying to remove it. The architecture begins protecting specialists more effectively than customers, and the system slowly evolves towards preserving itself rather than serving the business.

The Map Becomes More Important Than the Territory

Software has become one of the few engineering disciplines that occasionally mistakes the map for the territory. Architecture diagrams, governance processes, deployment pipelines and dependency graphs begin receiving more attention than the customer journey they supposedly exist to support. Organisations optimise representations of the system while slowly losing sight of the system itself.

Customers never experience architecture. They experience outcomes.

Everything else exists solely to reduce the distance between those two realities.

The Measure of Engineering

The disciplines confronting the greatest objective complexity devote extraordinary effort to making operation appear simple. Crossing a suspension bridge demands no understanding of resonance frequencies. Boarding an aircraft requires no knowledge of compressor stall margins. Patients rarely appreciate the astonishing biological choreography sustaining modern surgery because good engineering hides its sophistication behind predictable behaviour.

Perhaps software should aspire to the same standard.

The measure of engineering has never rested on how much complexity we can construct. It has always rested on how much unnecessary complexity we can remove without sacrificing capability. Humanity routinely launches reusable rockets into orbit, manufactures processors containing billions of transistors and performs surgery guided by machines capable of imaging living tissue in extraordinary detail. None of these achievements celebrates its own complexity. Every one seeks to hide it behind reliability, predictability and simplicity.

Perhaps software never suffered from an unusual abundance of complexity. Perhaps it suffered from an unusual willingness to admire it.

Those are not the same engineering culture, and only one of them consistently produces organisations capable of moving faster than their competitors.