We recently came across the concept of Technical Debt. This has been coined by the software development community to give a name to the shortcut option taken to save time instead of using a better approach that takes longer but is maintainable and extendable.
What is Technical Debt?
Technical debt is analogous to monetary debt. Building on shortcuts to save time is akin to accumulating interest on a loan. The longer it goes on the more interest accrues that will need to be repaid at some point.
In the same way that monetary debt is not always bad, technical debt is not automatically a bad thing. Deliberate technical debt can be incurred to create, for example, a proof of concept demonstrator which deliberately omits to deal with corner cases nor implements the features in a supportable manner.
Electronics Hardware
I believe that the same concept of Technical Debt applies equally well to the world of electronics hardware.
It is perfectly possible to quickly put together a hardware demonstrator for a project. This may well ignore tolerancing of components, managing oscillator frequency drift, dealing with harsh but rare input condition. For example, over-voltage transients, working at a higher power consumption than could be achieved to trade battery life for implementation speed. This omits some user features and ignoring electromagnetic compatibility compliance, ESD protection and good printed circuit board (PCB) layout.
So long as it is understood that the demonstrator is a means to an end with engineering corners cut then this is a pragmatic approach to gaining customer feedback or proving a concept works. It is easy at this point to get caught up in the enthusiasm of having a demonstrator and pushing to get the “product” into volume production. This is where technical debt often needs to be repaid.
Going from making 1 or 2 units to making hundreds or thousands plus units will quickly highlight issues from the demonstrator. At the point of volume manufacture component tolerancing can push a “working” design into becoming marginal where sensors cease to properly sense, radio’s stop working as their centre frequencies move too far apart. This causes units to die for unknown reasons or units fail to meet compliance. At this point, the short cuts that helped get past the first development stage can quickly begin to need repaying.
Experienced engineers can’t be substituted
Ultimately there is no substitute for proper engineering with experienced engineers. Engineers who have previously been there made the mistakes and have then had to fix them. Whenever shortcuts are taken it is key to keep in mind that what is done today for reasons of expediency will likely need to be redone tomorrow properly.
Quick engineering to cover the basics and get to an MVP (minimum viable product) stage is useful. Just as useful is a product that meets the full requirements, achieves compliance and that is fit for purpose in its environment. One takes longer than the other.
If you have any further questions about technical debt, don’t hesitate to get in touch.