When changing one feature repeatedly breaks another, the problem may be deeper than an unlucky bug. This lesson connects tangled responsibilities, deferred technical debt and missing automated tests to the difficulty of making safe changes.
Carlos Sanabria explains the symptoms a founder can notice and the engineering questions that help turn those symptoms into a focused improvement plan.
What you'll learn.
- Look for responsibilities that are too tightly connected.
- Include technical debt work in regular planning.
- Use tests to check important behavior before releasing changes.
Recognize tangled responsibilities.
A single oversized file or component may mix interface code, business rules, authentication, payments and integrations. When these responsibilities are deeply entangled, it becomes difficult to predict the effect of a change.
The important issue is coupling, not simply whether the application runs as one deployable system. A well-structured monolith can have clear boundaries. Ask whether the team can change and test a responsibility without unexpectedly disturbing unrelated behavior.
Connect symptoms to technical debt.
Small bugs, repeated release delays, outages and emergency cleanup can be signs of a fragile foundation. Carlos describes code that developers avoid touching because its behavior is difficult to understand.
Ask the team to connect the symptom to a specific part of the system. A useful explanation identifies the dependency, missing boundary or absent check that makes the work risky. That is more actionable than labeling the entire codebase bad.
Plan improvement work alongside features.
Separate responsibilities where doing so makes change safer, review coding practices and include debt reduction in routine planning. Waiting for an emergency can leave the team with fewer options and less time to understand the problem.
Architecture should fit current needs and realistic growth assumptions. Define the behavior or capacity you need to support, then decide which change addresses the constraint. More components are not automatically a better structure.
Use automated tests as feedback.
The recording compares repeated regressions to a problem that grows new heads when one is removed. Automated tests help by checking expected behavior when the code changes and flagging failures before users encounter them.
Tests provide confidence in the behaviors they cover; they do not guarantee that a release has no defects. Focus the conversation on important customer journeys, meaningful regression checks and how the team uses failures to stop or investigate a release. Clear structure and useful tests reinforce each other.
Safer delivery comes from understandable responsibilities, deliberate maintenance and checks that reveal unintended changes. Ask for evidence that the team can improve the product without making every release a gamble.
