Why CIOs need a complexity meter

With an existing software application and data services stack now being inter-married to new cloud services and a plethora of even newer low-code and no-code software functionalities, the C-suite IT team needs to formalise its measure of code complexity if it is to avoid technical debt and system disruptions in the future. Sourcery founder Tim Gilboy takes aim at IT technical debt.

IDGConnect_CIO_complexity_meter__code_shutterstock_2131508163_1200x650
Shutterstock

Modern IT stacks are complex. Despite the fact that we are applying an increasing amount of Artificial Intelligence (AI)-based autonomous and abstracted automation into the way enterprise IT is managed, the genome of the systems we are constructing beneath are increasingly complex.

Because our existing enterprise software application and data services stacks are now being inter-married to new cloud services and a plethora of API interconnections and functionalities, complexity at the code level itself is essentially increasing.

With complexity comes computing power, obviously. But the greater entanglement of more software code itself also increases the risk of creating technical debt.

Not a financial term per se (although it creates and incurs a direct cost in time-hours and resources), technical debt is of course the ‘repayment’ the IT team needs to expend to debug and fix software that has been created over-quickly, with appropriate consideration for integration or without enough foresight to plan for longer-term scale and so on.

To balance its books going forwards, the C-suite IT team needs to formalise its measure of code complexity if it is to avoid technical debt and system disruptions in the future.

To continue reading this article register now