Technical Debt and the Need for a Multidisciplinary Approach to Cybersecurity


Cybersecurity is big business. The Cyber Observer Website [1] has a plethora of figures about the increasing costs of cybersecurity breaches and the need for Information Security professionals. The evidence is incontrovertible – cybersecurity threats are the plague of the online industry in general – and IT departments in particular.

Many such topical websites focus on the ‘standard’ facets of cybersecurity – by which I mean penetration testing, threat analysis, the management of malware, its diagnosis and prevention. The above website [1], however, in quoting the eight most common causes of data breaches, produces the following list:

  • Weak and Stolen Credentials, a.k.a. Passwords
  • Back Doors, Application Vulnerabilities
  • Malware
  • Social Engineering
  • Too Many Permissions
  • Insider Threats
  • Improper Configuration and User Error [1]

It is interesting to note that in the above list over half of the threats are related to a lack of user education and technical errors within the software artefact itself. So while a focus on ‘traditional’ cybersecurity skills (the aforementioned facets) is an invaluable means of diagnosing and investigating vulnerabilities and even establishing the attack surface of a product or system, it is often not the best way of mitigating such errors once discovered.  Although many anti-malware vendors will happily sell you multiple products that will hide or patch security holes, the best cure is prevention – by which I mean ensuring that the vulnerabilities do not exist in the first place.

Quality, Security & Technical Debt

Traditionally software engineering degrees (and to a lesser extent computer science degrees) have not explicitly focused on security considerations and quality which inevitably has led to a profusion of security-related bugs or faults akin to those mentioned in the list above. These bugs ultimately contribute to an increased attack surface and increase costs by becoming part of the system’s technical debt – caused by implementing an alternative (often temporary) solution.

Martin Fowler of Thoughtworks wrote an article that described technical debt in a quadrant model as shown below [3]:

The model proposes four factors that affect technical debt: recklessness, prudence, deliberateness and inadvertence. He makes the point that technical debt is a metaphor and as such has value in representing the effect of design decisions made with the combinations of some or all of the above factors. In particular, it also illustrates that technical debt decisions can be made due to a lack of training and education (see bottom left quadrant).

Another contributing factor to the technical debt phenomenon is the agile development and management process. The triple constraint model [4], often used as part of that process, is the classic project management model used to illustrate the major constraints on any project – that is that any project is constrained by cost, scope and time but only two can be controlled at any instant – and that model has contributed to justifying technical debt in the deliberate/ prudent quadrant. However, if the project manager had an understanding of architectural design then s/he might make a different decision around the cost and impact of technical debt.

Another factor contributing to the debt challenge is expressed by Davis in ‘Great Software Debates’ [2] where he notes “Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to development success and absolutely requires knowledge of multiple disciplines.” The demands of agile software development – including the increasing emphasis on cybersecurity – have only accelerated this need.

Education To The Rescue?

The reality is that there is a myriad of factors that contribute to the technical debt – and by implication, the security  – of any software system. A contemporary lead developer, architect or project manager needs a good understanding of as many of those factors as possible which implies a good breadth of knowledge – and this is what modern cybersecurity degrees, such as those provided by the University of Essex Online (UoEO) (amongst others) aim to supply. The UoEO degree, for example, includes modules in secure development, secure systems and a research project, as well as more traditional cybersecurity modules in networks and information systems management, risk management and digital forensics to deliver as wide a base of technical and policy-based knowledge as possible. This is designed to help address a number of the issues discussed in this article – for example, looking at the list of data breaches provided above it provides modules that address each of them – producing much more capable staff with an enhanced appreciation for security and armed with the skills to ‘pay down’ technical debt more quickly – or even avoid occurring it in the first place. That same institution offers a similar conversion masters in computer science that addresses the need for multi-disciplinary project managers as well. 

An investment in this kind of education should be seen by employers as a way of offsetting the cost of technical debt that would be incurred by a lack of training and/or misinformation as well as a way of mitigating security risks and reducing attack surfaces. From an individual perspective gaining multidisciplinary qualifications such as these in growing and in-demand industry segments should be seen as a worthwhile investment in professional development.

Douglas Millward is a highly experienced computer consultant and technical architect, currently providing consultancy for the University of Essex Online (UoEO) as an SME and visiting lecturer.


[1] Cyber Observer. 2020. 29 Must-Know Cybersecurity Statistics For 2020 | Cyber Observer. [online] Available at: <> [Accessed 14 April 2020].

[2] Davis, A. and Zweig, A., 2015. The Missing Piece of Software Development. Great Software Debates, pp.125-128.

[3] Fowler, M., 2014. Bliki: Technicaldebtquadrant. [online] Available at: <> [Accessed 14 April 2020].

[4] 2020. Project Management Triangle: A Triple Constraints Overview | UK. [online] Available at: <> [Accessed 14 April 2020].