Technical Debt - the 'ultimate' strategy

-

(first published 30th October 2017)

WHAT IS TECHNICAL DEBT?

Technical Debt is quite a complicated subject to describe. For a simple explanation, read this great blog by Martin Fowler.

WHY IS TECHNICAL DEBT IMPORTANT?

Any software solution more than a year old is guaranteed to have some level of Technical Debt because, within that timeframe, someone will have taken a short-cut or made a tactical decision that will make further changes harder in the future. Working closely with our customers, we are seeing systems that have been in place for years and are, therefore, likely to have higher levels of Technical Debt.
In understanding our customers' needs, we are seeing that they are struggling to respond quickly enough to their customer and portfolio demands, making them vulnerable to new market entrants or at risk of losing market share.
As we work with our customers to understand their business needs better and ensure we continue to provide the right products and services to them, we are increasingly seeing that the root cause of many of their issues often comes down to an excess of Technical Debt. Short-term or low-cost decisions have built up over time, compounding the problems and eventually significantly slowing-down their ability to deliver new offerings to their markets and customers.

WHAT ARE THE ELEMENTS THAT CONTRIBUTE TO TECHNICAL DEBT?

When assessing how 'painful' your Technical Debt is, or 'how much interest you are paying', we can identify certain contributing factors:
  • Loss of tacit knowledge of legacy systems through attrition
  • Complex and disparate application landscapes due to 'organic' growth
  • Complexity of code, increasing cost of support (either poorly written or overly complex)
  • Age of platform or language
  • Ability to resource the right people to effect the change (domain, language or platform knowledge)
  • Market or customer perception of the product's longevity
  • Lack of tests to de-risk changes to the area
In essence, it is the contributing factors that represent the total cost of ownership of supporting, changing or integrating with the piece of software. This cost affects the business not only in terms of actual operational cost, but also in terms of customer perception and opportunity costs.

THE 'ULTIMATE' STRATEGY FOR TECHNICAL DEBT

Picture your company and your Technical Debt as a flooded basement. It would be good to know that everyone knows there's a flooded basement, from the Board downwards. It would also be good to see that there are some people in the basement with buckets, who've formed a line out into the driveway and are pouring the water away down the drain…
However, as you look at this picture, can you see if anyone has actually turned the tap off?
Are you still creating more debt every day? And if so, shouldn't you be turning the tap off first?

THE FIRST STEP IN 'TURNING THE TAP OFF'

To stop continuing to create Technical debt, it's all about the quality of the decisions the company makes collectively and the quality of the code created. Getting the company to change how it makes product decisions is a multi-faceted, context-sensitive answer requiring stakeholder engagement, communication and change. This can take a while.
So, while you start work on educating your peers, employees and bosses about the fact the basement is flooded and the need to change their decision-making, you can achieve some easy wins to help fix the leak.
Some things you can do for relatively little pain are:
  • Agree and communicate coding standards across all teams working on the same platform.
  • Integrate coding standards into the process – static analysis, build errors/warnings, gated builds and developer education about quality and your expectations.
  • Integrate security standards into the static analysis and build cycle, for example, SonarQube/OWASP checks.
  • Introduce pair-programming.
  • Adopt and encourage refactoring.
  • Introduce test-first principles and automation at unit, integration and functional levels.
  • Ensure regular technical uplift on platforms, tools and third-party components.
  • Use 'information radiators' (code, build and test monitors).

IMPACT

'Turning the tap off' has no immediate or short-term visible impact for your customers. Depending on the size of the organisation, the debt and the capacity you have for change, the impact of these simple changes could have a feedback loop measured in months, or even years, as far as your customers are concerned.
Everyone knows it's the right thing to do, but often companies do not deal collectively with the problem, favouring shorter-term gains. Then the Technical Debt builds up over time until the crisis of being slow to market becomes the primary strategic priority for the entire company.
The 'Ultimate' strategy is not to create Technical Debt in the first place, by investing in quality software production capabilities, making sustainable decisions, and continuously refactoring the landscape.
More information on some practical ideas of identifying, prioritising and working through the removal of Technical Debt is available at:

Comments

Post a Comment

Popular posts from this blog

Lost in Translation

-
Enterprise Scrum - Tactics for Implementing Agile Practices If you are implementing agile practices, methodologies and organisational changes within the company without full executive support, you are probably facing an uphill struggle. I was watching a TV documentary on the space race the other day, and one of the interviewees stated that in today's world nobody takes any real risk... This is fundamentally the problem you face, agile is perceived as high risk and difficult to manage. From a traditional management perspective, it is! Agile is about recognising there is a limit to control, that all things are not predictable, and that although we have clear objectives and a general direction, the detail of functionality and architecture is unknown at the beginning of a project. Managers need to learn an empirical approach to work and ensure that feedback loops and frequent communication are embedded within the fabric of the organisation. So with so much risk... cost, direction, cont
Read more

Starting Out

-
I left Conchango and started in my new role at the beginning of March this year. I'd been working as Scrum Master ( www.controlchaos.com ) with the likes of Howard van Rooijen ( http://blogs.conchango.com/howardvanrooijen/default.aspx ) and Ian Shimmings ( http://blogs.conchango.com/ianshimmings/default.aspx ), and fundamentally wanted to take agile practices to an organisational level. Moving a development team of 25 from traditional methods to agile practices is an exercise in change management. But even the word change management implies a clear direction, manipulation or cohersion and "management" of the process. I knew straight away that in order to encourage adoption of agile practices I would need to capture hearts and minds rather than direct a change programme. My previous blogs discuss transformational leadership and emotional intelligence, and I recognised that this is how I want to lead development. Even writing (I want to lead development) seems to go against
Read more

Breaking the Iron Triangle: Project Manager v Scrum Master

-
Image
As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines. And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders. But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager: · The Iron Triangle · The Role of Project Manager The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group. Previously
Read more