Moving through any agile transformation, organizations will find themselves constrained between the need for speed (velocity) and the need for quality. Technical debt becomes the enemy of velocity, and trade-offs are made between paying down existing debt, pushing out features, and if we’re lucky, avoiding the creation of more technical debt. Before long the organization is stuck with a Gordian Knot of code and find themselves with sword in hand ready to re-write the application. It doesn’t have to be this way. Peter Drucker is often quoted as saying “Culture eats strategy for breakfast” so what if instead of creating a culture based around accruing and paying off technical debt you shifted towards a culture of building technical wealth?
Technical Debt is any code that is difficult to understand.
To begin a conversation about building technical wealth, we first must understand technical debt – fortunately the analogy exists specifically to make the concept easier to understand!
Technical debt (also known as design debt or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.
Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later-on. Unaddressed technical debt increases software entropy.
Put more simply: Technical debt is any code that is difficult to understand. This can be the result of a myriad of coding habits, which we’ll discuss later. Like monetary debt, there are some instances where technical debt is necessary, or even advantageous, but these opportunities are less common.
Understanding what causes Technical Debt
Happy software shops are alike; Unhappy software shops are all unhappy in their own way. A core set of great practices aligned with company culture are the key to paying down technical debt and beginning to amass technical wealth. Without a well-defined and enforced set of great practices across an organization’s coding languages, the accrual of technical debt becomes an inevitability. By establishing, and improving upon these practices however, technical debt begins to be paid down, and eventually code bases will become easier for everyone to understand, modify, and build on top of. Development will accelerate, and technical wealth will be established.
Building Technical Wealth
An organizations culture is defined by the worst behavior which it tolerates. In development this often is seen as low rates of commenting, or increased usage of short-code identifiers – shortcuts that help us write faster now but may be costly later when trying to understand what was written. The following pages identify the top 3 critical insights to building your technical wealth.
Leverage Standard Units of Measurement Across your Organization
The beginning of your journey from Technically in Debt to Technically Wealthy relies first on objective, standardized units of measurement. Typical ways of assessing your application portfolio are time & cost consuming – even worse, they rely on subjective measurements leading towards biased viewpoints. Wrong Data lead to Wrong Decisions. Application Portfolio Analysis (APA) collects information about the application portfolio from an objective perspective, where the data collection process comes directly from a code scan. For the information that cannot be derived from a pure scientific method, APA leverages an online survey with specific questions that require closed answers (e.g. how many releases per year, original creation date, etc.).
APA will provide visibility into: risk, complexity, technical debt & resource allocation – at both the portfolio and individual applications levels. These objective metrics are critical to document before starting your journey towards technical wealth as they provide not only a baseline for comparison, but also will target potential expensive and risky areas within your application portfolio.
Identify Complexity to Control Technical Debt
Technical debt is directly correlated to both the quality & the complexity of the end-product. It measures the effort required to fix coding and architectural violations that remain in the code when an application is released. Unfortunately, the technical debt tends to grow more exponentially than linearly, which threatens some critical factors such as a) the overall portfolio agility; b) the number & cost of resources to fix; and c) the time to market. Utilizing predictive pattern analysis, you can identify the persistent coding practices that are negatively impacting technical debt and emphasize the practices the eliminate it.
Technical debt awareness should be conveyed through frequent monitoring and communication with teams. The more mature the teams become on this metric, the higher the opportunities are to pay down existing debt and begin building technical wealth.
Monitor Portfolio Health
Without consistent monitoring, software development tends towards entropy. Utilizing continuous monitoring is the most successful way to drive continuous improvement. These unbiased analytics become one of your best allies to communicate the baseline and the starting point of introducing fact-based measurements to push a continuous improvement culture.
The trends and benchmarks represent additional tools to compare with peers and monitor the trends over time. Insight into the progress of your rationalization over time will give everyone to confidence to continue to improve the quality of the application portfolio.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.