If you’ve taken a look at agile forms of software development you may have come across the concept of Technical Debt.
Wikipedia defines Technical Debt as: “…referring to the eventual consequences of poor software architecture and software development within a codebase.
Common causes of technical debt include (a combination of):
- Business pressures, where the business considers getting something released sooner is of more value than avoiding technical debt
- Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
- Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
- Lack of documentation, where code is created, but may be difficult or time consuming for anyone other than the author to understand, as functions are not documented
“Interest payments” are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of “paying off the debt” in the future.
Best Practice in paying down technical debt is to refactor code as part of ongoing development.” (Wikipedia)
This is a very useful concept – and one that certainly resonates with my experience of coding and software development. I like this because it allows for reality – yes you will cut corners, yes the architecture can get out of kilter, and the result is technical debt. This is a normal situation because of the business reality within which all development occurs – yet to avoid getting into too much debt, it needs to be paid off, by investing in technical tidying up from time to time.
Steve McConnell has an excellent article on technical debt that classifies it – depending on how intentional the debt was and how the debt was incurred. This tries to put the debt into business terms – an exchange of quality for time. Cutting corners leads to a reduction in quality, yet time to complete a project is reduced. The quality needs to be fixed later (paying down the debt) but doing so incurs additional costs (the cost of tearing down the area of poor quality and then building it right, and the cost of building it wrong in the first place).
All this is very well – however I’ve recently come across the term of Enterprise Debt (see PEAF for a slide show).
This is used in the context of business architecture. Business architecture gives the design of a business area or function. It contains processes, organisation units, competencies, IT systems, etc and explains how they all fit together.
As an intellectual exercise, business architecture is similar to software design. And therefore it too is subject to debt – except in this case under the title ‘enterprise debt’.
We’ve all worked in organisations where management have taken short cuts in setting up the organisation – where processes may be inefficient or just plain wrong, the team lacks the right skills, or any one of a whole range of everyday niggles about how the business functions. And these niggles result in the business just not performing to its ultimate capability – there is some kind of system yield or impedance at work causing loss in efficiency and effectiveness. This can be quite significant. If, for example you are only running at 70% effectiveness, and 70% efficiency – then that means you are losing out over 50% of your full potential. A business could double performance if only it could architect its business to become 100% effective and efficient (a laudable wish, but not really possible). Yet – surely we can improve on the 70/70 performance – and a modest investment that leads to a small improvement in performance usually offers an excellent ROI.
This whole concept has changed how I look at those difficult discussions with management – why we need to spend time doing maintenance instead of developing new things. The language of debt and the consequences of bad debt are an easy one to communicate and the organisation benefits from having an adult discussion about the options rather than the pointing and blaming that often goes on in its place. Take a look at the links and see what you think.
Recent Comments