Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Technical debt: Hot to assess it and manage it

Nick Dvas, COO, Servers.com | Jan. 4, 2016
As with any kind of risk, technical debt is beneficial when properly managed.

Although vendor-written, this contributed piece does not advocate a position that is particular to the author’s employer and has been edited and approved by Executive Networks Media editors.

Although it has never received proper consideration from a management point of view, “technical debt” is a popular concept among developers. Indeed, it is an idea useful for managing any company with a software development department.

Developers tend to describe technical debt as a consequence of deadline pressure, when, in order to deliver a product on time, developers have to cut some corners here and there, make compromises, and leave open wounds on a shadowy matter named code quality.

From an engineering point of view, technical debt can be described as a choice in software design made to satisfy short-term needs but capable of harming a long-term ontogenesis of code.

From a managerial standpoint, technical debt is not a debt, but a risk of increasing cost or schedule of development on account of current development process and its outcomes. Any decision made, any line of code written and any functionality delivered is naturally bound to a certain risk. The only circumstances under which you can develop with equal efficiency, regardless of what exactly is being developed, is the absence of any code to stay compatible.

On a qualitative level, the concept of technical debt is apprehensible. However, as with any risk, it is sometimes necessary to quantify it. There are several indicators of the amount of technical debt:

* Estimate accuracy.  Without technical debt present, in an ideal word, developers’ ability to estimate time required to develop a particular feature would evolve and become more accurate. Increase in expertise in project domain; better knowledge of used tools and frameworks; ability to predict performance of other team members – theoretically this all would make estimates of any developer and of the development department as a whole more precise. Should the opposite happen, it means the system is getting out of control. The loss of accuracy in estimates can be measured, and this measurement can give you a very good idea about the amount of technical debt accumulated.

* Time to first feature. Another useful metric is time to first feature by new hires. A period of adaptation is always required when a new developer joins the team. This period is determined by two factors: aptitude of the code for comprehension (the shape of the learning curve), and speed at which the developer moves along this learning curve (his own capacity to learn). Both of them are important. However, if on average new hires require more time to bring new features to your production environment, it is pretty likely that the learning code has become too flat – and it is the technical debt to blame for it.

 

1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.