Holistic engineering is the practice of factoring all non-technical variables into technical decisions so that architects and engineers solve for the whole system, not just the code. Those variables include organizational dynamics, career incentive structures, product strategy, world events, and the realities of people’s lives. Ignoring them does not eliminate their influence; it simply makes the resulting architecture less predictable and harder to change.
Key Takeaways
- Career frameworks that reward visible impact push engineers to add code to shared, widely-used services rather than doing the right architectural work, because a link to a popular PR is easier to present in a performance review than six months of disciplined refactoring.
- A monolith nobody dares to touch on a Monday morning in a planned sprint will still have to be handled on a Saturday night when it breaks in production, making fear of change a larger operational risk than the change itself.
- Holistic engineering means factoring non-technical variables, including product strategy, legislation, people’s life events, and org dynamics, into technical decisions, because those variables directly shape the code that gets written.
- Cirque de Soleil coding, stuffing every available design pattern and new library into a feature, signals a culture that rewards complexity over simplicity and raises long-term maintenance costs beyond what the feature justifies.
- Architecture and team structure must be aligned with product domains, because a mismatch between team boundaries and system boundaries creates flow blockages that no technical decision made inside those constraints can fully resolve.
Why architecture drifts away from best practice
Software architecture rarely follows the answer a technologist would give when asked for the right pattern. It follows the forces around the people who write the code. Career frameworks, delivery pressure, role models, and team culture push software in one direction or another, and the result often has little to do with any technical choice.
Vanessa Formicola describes this gap directly. Ask the technologists what best practice is, and they give the right answer. Then look at the actual system, and it looks nothing like what they described. The reason sits outside the code.
Seven recurring architectural patterns show up across different companies, and each one has a human or organizational cause behind it. The point is not to memorize the patterns but to learn to read the behaviors that produce them.
The kitchen sink: a shared service nobody owns
The kitchen sink pattern is a shared library or utility service that every team dumps functionality into and no one truly owns. The English phrase “everything but the kitchen sink” captures it: you stuff in everything you can think of, useful or not.
It starts small. Team A wants to share something between two of its services, which is fine. Team B decides to reuse it. Then the third, fourth, and tenth team join in. The first two teams may have tracked duplication and testing. The later teams do not.
As the service grows, fewer people know what is inside it, and no one refactors it. The blast radius when something breaks becomes large, the complexity rises, and the bug count follows. Shared ownership with no owner is the worst version of ownership.
Two non-technical forces drive this. One is the career and performance system. Many frameworks say people are as senior as the scope of their impact, so adding a small function to a service used across the company becomes an easy way to claim broad impact in a review. The other is delivery pressure. Under an unreasonable deadline, people cut corners, and reusing an existing connection point is faster than integrating properly.
Be careful what you measure, because you get what you measure. A career system that rewards visible reach across teams will produce services that sprawl across teams.
Cirque de Soleil coding: sophistication for its own sake
Cirque de Soleil coding is when even a small feature is packed with every design pattern, every library detail, and every newly released tool the author could reach for. Like the acrobats the name refers to, the sophistication becomes the point of the show.
The cost lands twice. You pay more than the feature needed in the first place, and you pay again to maintain it. The deeper problem is cultural: coolness gets valued over simplicity, and simplicity is the mark of professionalism.
Three forces feed this pattern. Career frameworks that ask engineers to prove breadth of skills push people to demonstrate it in a single pull request, because a manager rarely reviews six months of work to confirm someone has the skill. A respected role model with a taste for elaborate code sets the tone, and juniors copy it to prove their own value. And a toxic team culture of one-upmanship, where colleagues compete by adding one more clever thing, fills pull requests with code nobody needs.
None of this is technical practice. It is human behavior expressed through code.
The monolith constellation: fear turned into risk
The monolith constellation forms when a sensitive service becomes something nobody wants to touch. It is poorly understood, usually untested, and risky to change, so teams stop changing it and start building around it instead.
The service sits at the center like a star. Teams treat it as a black box: they know what goes in and what comes out, and they wire new services around the edges. The result is complexity radiating outward and a blast radius that keeps growing.
Vanessa puts the core question bluntly.
If you’re scared of changing it on a Monday morning in a regular sprint, I want to know what you are gonna do on Saturday night when it breaks in production. — Vanessa Formicola
The cause here is under-investment in the cost of not doing something. When refactoring has no official time and carries personal risk, even a diligent engineer will leave the service alone rather than put their own career in jeopardy. If the whole company does not commit time and accept the risk, no individual will. The risk just sits there, ignored.
The three monkeys: ignoring what is not “technical”
The precondition for better architecture is admitting that non-technical variables shape the code. Architects and engineering leaders often behave like the three monkeys: they see problems between people, in the product department, in HR, and they leave those problems out of their technical analysis because they feel petty or unscientific.
Those variables have a direct impact on the code. They are what pushes a project past its deadline. Closing your eyes to them does not make them disappear.
You may not be able to change all of them. You can change some, and you can mitigate for all of them. The first move is to make the implicit forces explicit and to help the people around you see them too, so factoring them in becomes legitimate.
Holistic engineering: solving for the whole system
Holistic engineering means factoring all the non-technical variables into your technical decisions, so you solve for the system and not only for the technical view. The medical analogy fits: holistic medicine treats the individual and the environment that caused the illness, not only the symptoms.
The variables split into external and internal groups. Both matter, and both are usually underweighted.
External factors sit outside the organization but reach into it:
- Tech trends, which you assess for their positive or negative effect over time rather than adopting wholesale.
- Business trends, which tell you where the product is heading and therefore which parts of the system may change.
- World events, from the obvious ones like Black Friday and Christmas to the ones many teams miss: elections, legislation, and shifts such as digital sovereignty.
Internal factors break into four areas that deserve separate attention.
Organization: a living system you inherit
Treat the organization as a living system that existed before you arrived and will continue after you leave. Understand it so you can build on it, mitigate what you cannot change, and change what you can.
The org chart is not the real map. What matters is the actual flow of power and information, and the historical reasons why one thing is treated as good and another as bad. Career frameworks and reward systems are hard to change from your seat, so you often have to work around them.
Product: what stays and what shifts
Understanding the product means knowing which parts never change and which parts do. In health tech, some biological functions do not change, so those parts of the system stay stable. How the product presents itself and what services sit on top will change.
Knowing the difference tells you where to invest. And marketing campaigns can reshuffle priorities on a long-running project, so their power is easy to underestimate.
People: real lives, not interchangeable resources
Understanding your people goes past headcounts and seniority labels. For your key contributors, you need to know what is happening in their lives and how it will affect the work.
Someone getting divorced, having a child, caring for an elderly relative, or moving house contributes differently for a while. Two people who have fallen out may not work well together. When people share these things appropriately, you build mitigations, the same way you manage risk in software. Pretending people are interchangeable is not a plan.
Tech: strategy, security, and honest starting points
On the technical side, ask whether the work aligns with a technical strategy and whether that strategy even exists. Check that the change is a real step in the intended direction.
Security and privacy belong early in the thinking, because they can stop an otherwise excellent project outright. Be honest about your starting point: the true quality of a service and the cost of lower-level concerns can change an estimate completely.
Finally, check whether architecture, product, and teams are aligned. When a technical constraint forces teams that do not match the domain or the architecture, you get blocked flow and risks outside your control at the moment you decide.
Better decisions come from counting more variables
Business decisions in software are not very reliable, and almost no project ships on time. That is a peculiar state for an engineering discipline, and part of the cause is that we leave most of the system’s variables out of the calculation.
Software will never be an exact science. It can move closer to other engineering fields by factoring in more of what actually drives outcomes, starting from the fact that people make software and that every human aspect belongs inside the decision.
Why testers need the widest view
The whole-system perspective matters for every technologist, and it matters more for testers. To find the gaps, a tester has to understand the system, not just the isolated feature in front of them.
Depth of skill gets rewarded, and it is valuable. Seniority comes from breadth: understanding how a change ripples through the system rather than how good it looks in isolation. “That’s not my job” is the wrong answer when the organization, the people, and the product are the very things that decide whether the software works.
