A while ago, I was reading an article about a concept that at the time was unfamiliar to me, which it called “Technical Debt”, but as I read more I began to understand what it meant. The concept refers to the costs that companies have to bear to correct “bad jobs” that are often knowingly accepted in order to achieve other apparently more important objectives. But is this done knowing all the implications of these decisions?
In my opinion, “technical debt” has a lot to do with a short-term view of the context of the problem. The concept was created by Howard Cunningham, an American programmer who, as well as being the creator of the first wiki site, is well known for having worked on the design of robust software development methodologies. In 1992 (which shows it’s not a new idea), Howard published an article in which he cited the problem of “technical debt”, applying it to the development of collaborative software. The problem described is almost certainly familiar: development engineers take their projects forward by implementing new functionalities and leaving the tasks of debugging or optimisation “for later”. Finally, the pressure of time-to-market targets obliges the putting of the product on the market without carrying out these tasks, under the slogan “we all assume the consequences” … but without knowing what these might be.
The situation described is accepted in a surprisingly uncritical way in some areas related to software (we are all familiar with “Fatal Error” messages, the Windows “blue screen of death” and the use of Ctrl+Alt+Del). However, when “technical debt” is associated with other activities, such as the development of the hardware of the product, the implications may be different.
Frequently, the manufacturability of the product or optimisation in the selection of components incorporated in the product are not given as high a priority for the development engineers as the development of that innovative functionality that will boost the sales of the product. “It will cost what it should cost, and EMS will know where to get the components and how to manufacture the product. That’s their business, right?”
The design of the PCB, the functional validation of the prototype and the regulatory certification of the product represent a major effort, and once these milestones have been achieved, resistance to modifications is very high. Thus, the project progresses, forgetting about the potential points of “improvement”, such as facilitating manufacturability, having alternative components available to address problems of obsolescence or allocation of components or to reduce their cost.
But if these issues have not been addressed, we are creating “technical debt” in the form of potential improvements or action to reduce risks that cannot be adopted in an appropriate manner during the life of the product.
To help our clients reduce these problems, at IKOR we have carried out work in order to be able to implement different services throughout the life cycle of the product. These include BOM Analysis and Manufacturability and Test Analysis, which are focused on the improvement of the product during its development stage, when the changes are easier to implement, its cost is lower and the impact on the time-to-market of the product is minimal.
In this way our clients are able to reduce their “technical debt”, reducing risks and improving the profitability of their products.