Having recently read a little on Technical Debt ( http://1.usa.gov/JbZdYt ), I began to think about the subject, and came up with a couple of points I’m interested in:
- Does technical debt affect Operability?
- Should the metaphor should be extended to infrastructure and teams?
I’ve tried to keep to some brief thoughts below, I’d be very interested in hearing some other view points in the comments.
Do Software teams incurring technical debt need an eye on the future?
In the situation where you actively are choosing a compromise which increases your technical debt, failure to consider the pay back pain would compound the difficulty further and seems likely to be detrimental to Operability.
Development efforts which actively increase their technical debt levels should analyse whether this has an impact on future Operability, alongside other concerns such as stability, performance and features.
Dropping feature x need by the ops team and no external customer still should be assigned a value, even if overall consideration of the value of an operable system is primarily be influenced by deployment [sales] and usage modes of the product.
Can we rack up technical debt in teams and infrastructure?
I would argue that it is appropriate to extend the metaphor, consider that If we can accept the accumulation of technical debt in the process of design and development of software systems, extending the concept to encompass both technical teams, and infrastructure services is not a huge leap, and could be supported as follows.
A group of people often exhibits behaviour which could be observed as an unreliable system, we can cast technical debt as a lack of investment in skills development, team manager capabilities or mismatches between work and talents. There is little surprise that teams don’t always function at their optimum level.
Similarly, for infrastructure, we can define technical debt along the lines of under investment in hardware capabilities, lack of due care in implementation, poor design decisions.
Summary
With those thoughts in mind, I would suggest that without careful consideration Operability could easily be compromised, it’s not a great stretch to see how the very same difficult costs to pay off (in terms of tech debt) are encountered when considering how to build for the future when the team, infrastructure or foundation of both is unsound
Rob Thatcher 
One thought on “Technical Debt in Teams and Infrastructure”