What You Are Actually Copying

Reusing calculations from a previous project looks like an efficiency gain. The work has already been done, the numbers have already been checked, and the design it produced is already in production and functioning correctly. Taking that calculation package and applying it to a new project saves time and avoids duplicating effort that seems to have already produced a valid result. The logic is understandable.

The problem is that the calculation package from the previous project is not just a set of numbers. It is a record of every assumption that went into producing those numbers – the assumed load cases, the assumed material properties, the assumed boundary conditions, the safety factors that were chosen for a specific application with specific risk characteristics. It also reflects every compromise that was made during the design process and every error that was present when the calculation was completed. Some of those errors may have been caught and corrected. Others may have been present but benign in the original application – absorbed by margins that happened to exist for other reasons, or simply irrelevant to the way that particular design was loaded in practice.

When the calculation is copied to a new project, all of those assumptions, compromises, and errors come with it. And the new project has a different geometry, different loads, different constraints, and a different context. The assumptions that were valid in the original application may not be valid in the new one. The errors that were benign in the original context may not be benign in the new one. The margins that absorbed problems in the first design may not exist in the second.

Why “It Worked Last Time” Is Not an Engineering Argument

The phrase “it worked last time” has a surface plausibility that makes it more persuasive than it deserves to be. If a design using those calculations is in production and functioning without failures, that is evidence that the design is working under the conditions it is actually experiencing. It is not evidence that the calculations are correct, and it is not evidence that the same calculations will produce a safe result under different conditions.

A structural component can be functioning correctly in service for two distinct reasons: because the design is correct and the calculations accurately reflect why it is correct, or because the design has margins that absorb errors in the calculation without those errors producing a visible consequence. These two situations look identical from the outside. The component is in service. It is not failing. The design appears to be working.

The difference between them only becomes visible when the conditions change – when the load case is different, when the geometry is different, when the application context is different in ways that remove the margins that were providing silent protection in the original design. At that point, a calculation that was producing the right answer for the wrong reasons produces the wrong answer, and the design it supports fails in ways that were not predicted because the prediction was based on assumptions that no longer apply.

The Specificity of Boundary Conditions

Every structural or mechanical calculation is valid within a specific set of boundary conditions – the assumptions about loads, constraints, material behaviour, and geometry that the calculation is built on. Those boundary conditions are rarely fully explicit in a calculation package, because many of them are embedded in choices that seemed obvious at the time they were made and weren’t documented as assumptions because the engineer who made them didn’t think of them as assumptions. They were just the way the problem was set up.

The loads are a boundary condition. A component designed for a static load of a certain magnitude will not necessarily perform correctly under a dynamic load of the same magnitude, or a static load of a different magnitude, or a load applied in a different direction, or a combination of loads that the original calculation didn’t include. The geometry is a boundary condition. A change in wall thickness, fillet radius, or cross-section profile changes the stress distribution through the component in ways that may be significant or may be negligible, and the only way to know which is to run the analysis for the actual geometry rather than assuming that the previous result applies.

The material is a boundary condition. Material properties – yield strength, fatigue limit, fracture toughness, behaviour at elevated temperature – vary between grades, between manufacturers, and between batches. A calculation that used the properties of one material does not automatically apply to a nominally similar material with different actual properties. The application context is a boundary condition. A component that operates in a controlled indoor environment is being asked to perform differently from a nominally identical component that operates in an outdoor environment with temperature cycling, moisture exposure, and vibration from sources that didn’t exist in the original application.

How Failures Happen Quietly

The failure modes that result from copied calculations are often not immediate or dramatic. They tend to be gradual – fatigue cracks that develop over time in locations where the stress concentration was higher than the calculation predicted, wear patterns that emerge because the contact conditions were different from what was assumed, deformation that accumulates under repeated loading because the elastic behaviour assumed in the calculation was not the actual behaviour of the component under the actual loads.

These failures are particularly difficult to attribute correctly when they occur, because the calculation that was used to design the component shows that the component should be adequate. The investigation has to work backwards from the physical evidence of the failure to identify why the calculation was wrong – which requires understanding all of the assumptions that went into it, including the ones that were never documented because they seemed obvious at the time.

This is one of the reasons that borrowed calculations are more dangerous than calculations with explicit errors. An explicit error can be found and corrected. An undocumented assumption that was valid in one context and invalid in another may never be identified as the source of the problem, because it doesn’t look like an error – it looks like a reasonable engineering decision that happened to produce an unexpected result.

Engineering Means Responsibility for the Result

The fundamental issue with borrowed calculations is not technical – it is about responsibility. An engineer who produces a calculation for a specific application is taking responsibility for the adequacy of that calculation for that application. They have examined the load cases, made explicit decisions about the boundary conditions, selected the safety factors appropriate to the application context, and produced a result that they are prepared to defend.

An engineer who borrows a calculation from another project is not taking that responsibility. They are taking the result of someone else’s analysis of a different problem and asserting that it applies to their problem – without necessarily having examined the assumptions, understood the compromises, or verified that the boundary conditions are comparable. The calculation may produce the right answer. But the engineer has not done the work that would allow them to know whether it does.

Engineering means responsibility for the result. That responsibility starts with doing the calculations for the actual problem – with the actual geometry, the actual loads, the actual material properties, and the actual application context. It is not a longer path to the same destination. It is the only path to a destination that you can actually be confident about.