Temporary solutions often end up in the final product

“We’ll do it this way for now.”

It’s a perfectly reasonable sentence.

In R&D, you have to be able to move forward without solving every problem straight away. You use an available component, you quickly write an interface, you hard-code a value, you make a temporary part.

The goal isn’t yet to build the final product.

Only to test a hypothesis.

The trouble starts when the temporary works well enough that you stop treating it as temporary.

A prototype accumulates shortcuts #

A prototype isn’t a bad product.

It’s an object built with a different goal.

To answer a question quickly, it’s perfectly logical to accept things you wouldn’t accept in a final product.

• An oversized power supply.
• An external computer to run some processing.
• A machined part when it will probably have to be injection-moulded.
• A parameter set by hand.
• A library chosen because it lets you test an idea in a few hours.

Taken individually, each of these choices can be perfectly justified.

The danger appears when their temporary nature fades from the project’s memory.

What works quickly earns a special status #

Once something works, changing it becomes harder.

Not necessarily technically.

Psychologically and organisationally.

Why touch something that works?

A new feature arrives. Then another. They’re built around what already exists.

Tests are run with this architecture.

Internal tools start to depend on it.

The documentation describes it.

A few months later, the small choice made “just for the prototype” sits at the centre of the system.

It’s still theoretically replaceable.

But replacing it now costs far more.

Technical debt isn’t always a mistake #

Technical debt is often talked about as the result of poor development.

That isn’t necessarily the case.

In R&D, taking a shortcut can be an excellent decision.

Spending three weeks cleanly building a part of the system you don’t even know will still exist in three months would sometimes be absurd.

So the problem isn’t creating debt.

The problem is no longer knowing where it is.

A documented temporary compromise is still a decision.

A forgotten temporary compromise gradually becomes a constraint of the system.

The temporary needs an expiry date #

When a shortcut is deliberate, three pieces of information are often enough:

• Why did we make this choice?
• Under what conditions is it acceptable?
• When must we re-examine it?

That last point is probably the most important.

“To be replaced later” isn’t a deadline.

By contrast, these formulations define an observable event:

• “to reassess before the validation tests”,
• “to replace if we exceed 100 units”,
• “to reconsider once the electronic architecture is frozen”.

The project then has a mechanism to remember its own decision.

A prototype should be able to tell its story #

When you pick a project back up several months later, it should be possible to tell two things apart: what was designed this way because it was the right choice, and what was designed this way because it was the sufficient choice at the time.

The difference is fundamental.

Without it, the next team risks reading every existing element as the result of a carefully considered decision.

And building around it.

That’s how a piece of code written in an hour, a temporary mechanical part or a component picked out of a drawer can end up defining a product’s architecture years later.

Not because someone decided to keep them.

Simply because no one decided to replace them.