First of all, I’ll get this out there, I HATE the term ‘Technical Debt’ with a passion, it doesn’t help us in the relaying context, and to those in the business who aren’t working with ‘Technical Debt’, hearing the phrase sounds like hearing ‘my job isn’t easy I have so many problems, please make my job easier’.

Let’s talk context, let’s use not ambiguous phrases. So this blog post will discuss “improving development efficiency” but not ‘tackling technical debt’.

Very few organisations are in a position to say “we have nothing we’d like to improve in our system(s) and/or software delivery teams”. Even when a business has the all the people it needs with all the skills desired skills and mechanisms to make improvements, there are always things that could be better with the system(s) or applications, this could be any thing from the ownership of logic or validation between applications, to how an application is logging errors, to how domain boundaries are split.

A growing business, generally, is always trying to improve its offering. People come up with great ideas quicker than they can be coded, tested, deployed and used in a live environment. However, it’s important to take a step back once in a while to reflect on the system to see where we are, look at where we are trying to get to from a business perspective, and really understand what we require from our systems from an architectural view point. Sometimes it’s even worthwhile forgetting where we are and to just try to get an understanding of what we would like our system look like in the ideal world. Doing this at all levels from enterprise level to sub-system level is really important as the system design will otherwise be determined by project requirements. There be dragons down this road of Project Orientated Architecture. I won’t go into why in this blog post (that’s covered off in Organising-teams-for-a-good-architecture-part-1 and Organising-teams-for-a-good-architecture-part-2).

Having an evolving vision (which is bought into and contributed into by the relevant teams) at enterprise level, system level, sub-system/domain and application/service level allows us to increment toward the ideal whenever we are delivering new functional value. The key word here is INCREMENT. Trying to get to this vision in one go, is both risky and rarely cost effective. The ideal will always change as new technologies become available, new practices are adopted, and more importantly as the business matures more than is has already and thus changes its priorities. Incrementing toward the ideal architecture as part of the development process allows us to continually decrease the cost of development and support by just chipping away a little at a time. Obviously there may be big ticket things to improve such as moving from a relational database to some other form of database, but these should only be tackled when it is clear that there is business value in tackling the big ticket items.

However for this approach to be successful, it is important to understand both the expected amount of effort involved to improve each ‘unit’ and the value gained in improving each ‘unit’. This is only possible by retrospectively looking at a previous work stream (ideally immediately after it is complete), collating a list of all the issues that slowed the team down (as granular as possible), including build issues, logging issues, it has to be absolutely everything. For each of these issues the team needs to be able to give a conservative estimate on how much time they lost because of each issue. After getting a full list of issues and an understanding of impact, the next step is to categorise and sub-categorise these, this allows the team to look at the issues in a wider context and not just related to the specific issues independently.  Ideally all the sub categories should be easy to define and make it easy to pin point specific areas of improvements e.g. message logging rather than just logging in general. Now, assuming we have specific areas of improvement, the team should hopefully be able to give an indication of the effort involved to resolve each sub-category of improvements, along side the estimated ‘cost of not fixing’, this can now be turned in to an ROI model to pick up the highest value items first along side each project in that area, or if required, we now have the business case for technical improvements for a specific area.

The important thing to realise is that the ideal architecture will (and should) always be a moving target that we are moving toward, technology always improve, frameworks get better, development practices become more mature. No matter what we do, at some point there will be something that could be improved. But we should always be continuously improving, this is the only way for use to ensure that we are able to continue to move as quick as we would like to move and can keep ahead of the competition where the industry is moving quicker and quicker. If you get to what you defined as the ideal architecture, then chances are it’s no longer ideal shortly after you’ve got there, or you’ll realise that there is a better way it could have been done.