Most software assessments are designed to answer questions about the present.
Is the system secure? Reliable? Maintainable? Can it scale? Is the architecture appropriate for the workload it supports today?
Those are useful questions.
But they leave an important gap.
Software does not operate under fixed conditions. Usage grows. Teams change. Dependencies evolve. Costs shift. Regulations appear. Customers ask for capabilities the original system never anticipated. Development practices change the rate at which software is produced and modified.
A system that is perfectly adequate today may become increasingly fragile as those pressures accumulate.
That gap is what I mean by software survivability:
Can this software continue delivering value as pressure increases?
Survivability is related to scalability, resilience, maintainability, reliability, security, and sustainability, but it is not identical to any of them.
A system may scale technically while becoming prohibitively expensive to operate. It may remain reliable while depending on knowledge held by one or two people. It may be maintainable in isolation while requiring so much coordination across teams that meaningful change becomes slow and risky.
And a team may dramatically increase the rate at which it produces software without increasing its ability to validate, understand, and safely operate what it produces.
The important question is not simply whether the software works.
It is whether the software can continue to work as the conditions around it change.
Success Changes the Conditions
Success is one of the most common ways pressure arrives.
A small product may begin with a straightforward architecture, a small team, modest traffic, and predictable requirements. That architecture may be entirely reasonable. Designing for every hypothetical future at that stage would probably be wasteful.
But success changes the context in which those early decisions operate.
More customers create more data. Larger customers bring new security, reporting, integration, and availability requirements. A growing engineering organization requires more coordination. Faster release cycles increase the number of simultaneous changes. A key engineer leaving can turn undocumented historical context into operational risk. A dependency change can expose assumptions nobody realized the system was making.
None of this means the earlier decisions were wrong.
The more useful question is whether the conditions under which those decisions were reasonable still exist.
This is one reason I tend to think of architecture as a collection of commitments rather than a collection of technologies.
Choosing a database, introducing a queue, splitting a service, adding a cache, adopting a framework, or automating deployment each solves a problem while also creating constraints.
Those constraints accumulate.
Systems remember those decisions even when the people who made them no longer do.
Pressure is often what makes those commitments visible.
A retry strategy that is harmless at low volume may amplify load during an outage. A shared database may be convenient while three developers work on the system and painful when several teams need to make independent changes. A batch process that runs once an hour may be perfectly acceptable until customers begin expecting near-real-time results.
The issue is rarely that a particular pattern is inherently bad.
Its consequences change as the conditions around it change.
Survivability Is More Than Scalability
Scalability usually asks whether a system can handle more work.
Survivability asks whether it can continue delivering value as different forms of pressure increase—often at the same time.
A service may easily handle ten times its current traffic while requiring nearly ten times the infrastructure cost. From a capacity perspective, it scales. Economically, it may eventually become difficult to sustain.
A system may have excellent uptime but poor internal boundaries. It remains operationally reliable while changes become increasingly risky because every modification requires coordination across several components.
A codebase may be well structured and easy to modify while depending on an external service whose limits have never been tested against expected future volume.
And AI-assisted development can increase the rate at which software is produced without increasing the organization’s capacity to review, validate, understand, and safely operate those changes.
AI made code abundant. Engineering judgment is still scarce.
These dimensions do not exist in isolation.
Growth may increase infrastructure costs. Cost pressure may produce architectural changes. Those changes may increase operational complexity. Increased complexity raises cognitive load and the likelihood of mistakes. Incidents slow delivery, creating pressure for more automation, which introduces another set of dependencies and commitments.
The original source of pressure may have been growth.
The eventual constraint may be organizational.
This is why survivability is less about compiling a list of defects and more about understanding consequence chains.
That way of thinking led us at Making Software Greener to develop the Software Survivability Review.
The Review does not ask, “What can we criticize about this system?”
It asks:
What does continued delivery depend upon, and what happens to those dependencies as pressure increases?
When Nothing Is Broken Yet
One pattern explored in our composite sample Survivability Review involved validation.
The repository contained multiple validation paths across subsystems and integrations.
That is not, by itself, a defect.
Different parts of a large system may legitimately require different forms of testing and validation, and experienced contributors may know exactly which checks apply to the areas they are changing.
Under current conditions, that arrangement may work perfectly well.
Now change the conditions.
The team grows. More changes happen in parallel. Work increasingly crosses subsystem boundaries. Release frequency increases. AI-assisted development raises the volume of code being produced.
The validation architecture has not changed.
The pressure on it has.
If safe delivery depends partly on engineers already knowing which checks apply, increasing the number of contributors and the rate of change may turn contextual knowledge into a constraint. Missed or late validation can create rework, increase release uncertainty, and make delivery less predictable.
But even that does not prove there is a problem.
That distinction matters.
Seeing multiple validation paths does not justify declaring the architecture broken or proposing a sweeping redesign.
The next step is evidence.
Which checks are actually required? Which are consistently executed? Are they enforced by CI? Where do bypasses occur? Are cross-system changes measurably slower or more error-prone? Are failures discovered late because the correct validation was missed?
Only then can we distinguish between complexity the organization handles successfully and a survivability constraint that becomes more important as pressure increases.
That distinction—between what is wrong now, what may become limiting later, and what we do not yet know—is central to survivability.
Evidence Before Remediation
Technical assessments can easily become exercises in taste.
One engineer prefers events. Another prefers REST. Someone dislikes stored procedures. Someone else wants everything on Kubernetes.
Architecture is contextual.
A monolith can be an excellent architecture. Microservices can be an excellent architecture. Polling, queues, caches, scheduled processes, and manual workflows can all be reasonable choices.
A useful review therefore needs to distinguish observation from inference.
Suppose a service retries failed requests without meaningful backoff.
The retry behavior is an observation.
The conclusion that it could amplify load during a particular outage is an inference.
It may be a well-supported inference, but it is still a prediction about system behavior under conditions that may not yet have occurred.
Sometimes the evidence is strong enough to justify immediate action.
Sometimes the appropriate response is to measure, test, or investigate first.
That matters because architectural changes are themselves commitments. Replacing something merely because it might become a constraint can create more risk than leaving it alone.
The goal is not more remediation.
The goal is better evidence about where remediation is warranted.
That also means not assessed is a legitimate result.
If the available evidence cannot establish how a system behaves under a particular pressure, the answer should not quietly become “looks fine.”
It should remain unknown until the evidence supports a stronger conclusion.
A repository can reveal a great deal about architecture, security boundaries, dependencies, validation, and likely operational behavior. It cannot tell us everything about production traffic, organizational coordination, failure recovery, cost amplification, or actual human behavior around the system.
Knowing what the evidence cannot establish is part of understanding the system.
From Evidence to Survivability
A Survivability Review starts by understanding the system and the pressures it is likely to face before trying to evaluate it.
The process moves through five stages:
Understand → Observe → Infer → Consequences → Recommend
The sequence matters.
Recommendations made before understanding a system are often just preferences dressed as conclusions.
A review may uncover things that need action now: an unsafe security boundary, a dangerous configuration default, a validation bypass, or an obvious resource-protection problem.
It may also identify conditions that deserve validation because they could become limiting as pressure increases: coordination across subsystems, dependency concentration, deployment variation, reliance on maintained engineering knowledge, or validation processes that depend on contextual knowledge.
And sometimes the available evidence does not justify an answer yet.
Those are very different outcomes:
Act on what the evidence establishes.
Validate what may become a constraint.
Be explicit about what is not yet known.
That is more useful than maximizing the number of findings.
Twenty minor code-quality observations may matter less to the future of a system than one dependency on knowledge held by a single engineer. Several inefficient queries may matter less than a cost pattern that grows directly with customer volume. A complicated collection of test suites may not matter at all if automation reliably ensures that the right ones are always executed.
The point is not to find everything that could be improved.
It is to understand what continued delivery depends upon.
What You Leave With
The outcome of a Survivability Review is not intended to be a pile of findings.
It is a survivability judgment.
The review distinguishes between things that warrant action now and conditions that should be validated before the organization commits to expensive changes. It identifies the pressures most likely to expose current assumptions, traces important findings through their likely consequences, and turns those conclusions into prioritized actions and validation work.
A review can conclude:
Yes — the system appears capable of continuing to deliver value under the pressures evaluated.
Yes, with reservations — the system is fundamentally viable, but important conditions or risks deserve attention.
No, but improvable — current weaknesses materially threaten survivability, but there is a credible path forward.
No — fundamental conditions make continued value delivery under the pressures evaluated unlikely without substantial change.
The judgment matters.
But the reservations may matter even more.
“Yes, With Reservations”
Software rarely reduces cleanly to pass or fail.
A system might support substantial growth, but only while deployment frequency remains low. It might tolerate the departure of one experienced engineer but not several. It may support significantly more traffic while producing a cost curve the business will eventually reject. It may be highly reliable during ordinary operation while depending on recovery procedures that have never been exercised end to end.
In cases like these, “yes, with reservations” can be much more useful than either “yes” or “no.”
The reservations identify the assumptions under which the system remains healthy.
Those assumptions are often what we should be watching.
The goal is not perfect software.
A survivable system can have technical debt, compromises, awkward components, and decisions everyone wishes had been made differently. It does not need infinite scalability or an idealized architecture.
It needs enough room to absorb change.
Its important constraints should be visible. Its dangerous assumptions should be understood. The organization should know where growth may become expensive, where change may become difficult, where dependency concentration creates risk, and which apparent problems are not currently worth fixing.
Some risks can be accepted. Some should be monitored. Some require action.
The important thing is that those decisions are deliberate.
When Should You Ask the Question?
The most useful time to ask whether software can survive success is usually before—or immediately after—something changes.
Perhaps growth is accelerating.
A major enterprise customer is arriving.
AI-assisted development is increasing delivery velocity.
Cloud costs are climbing faster than expected.
A key engineer leaves.
The company acquires or inherits a system.
A due-diligence process begins.
A modernization effort is about to reshape architecture that has accumulated years of assumptions.
Or recurring incidents keep occurring without anyone being able to explain the whole chain.
These are not necessarily signs that the software is bad.
They are signs that the conditions around it are changing.
That is when previously harmless assumptions become interesting.
Every System Eventually Gets Tested
Most organizations eventually perform a survivability test whether they intend to or not.
Sometimes they do it deliberately.
Before rapid growth, a major customer launch, an acquisition, an organizational change, or an architectural transition, they examine where pressure is likely to accumulate and test important assumptions before circumstances force the issue.
Other organizations perform the same test in production.
Traffic increases. A key engineer leaves. A dependency changes. A large customer introduces unexpected requirements. Costs rise. Development accelerates.
The system encounters conditions it has not experienced before, and the organization discovers which assumptions mattered.
Both approaches eventually answer the same question:
Can your software survive success?
The difference is whether you choose when you find out.
This is no longer just a question we are exploring. Making Software Greener is now offering Software Survivability Reviews for teams approaching periods of growth or change.
See What a Survivability Review Looks Like
We’ve published a composite sample assessment showing how observations become evidence-backed findings, how confirmed issues are separated from conditions requiring validation, and how those findings become prioritized action.
Considering a review? If your system is approaching a period of growth or change, talk with us about the pressures you’re expecting.
No responses yet