In this article
Authors: John D. Gómez
Topics: Evolución de sistemas
Other edition: El coste de cambiar no termina en el código
A change may take a few hours to program and several days to coordinate. Measuring only the first part hides where the team’s capacity is being consumed. To decide what to improve, follow a change from the initial request through to confirming its behavior in operation.
Observe the complete journey
Choose a recent, representative change. Reconstruct what had to be understood, which decisions required waiting, which tests were performed and which interventions delivery required. Distinguish working time from waiting time. This provides a more useful basis than attributing every difficulty to the age of the code.
Identify the missing boundary
If several components must change together, ask what responsibility they share and whether their contracts are explicit. Physically separating them does not resolve the dependency on its own. An improvement should reduce an identifiable burden for the people who develop, test or operate the system.
Test a focused improvement
Choose one source of friction and define the outcome you expect to observe. It might be fewer manual interventions, a clearer understanding of impact or simpler recovery. Compare similar changes and also record any work shifted to other people. A local improvement is not enough if it makes the overall operation worse.
A question for the next review
Which part of the next change should become easier because of the decision we are making today? If the answer cannot be tied to a specific task, the proposal probably needs more context.