On Technical Debt http://www.ontechnicaldebt.com Online Community Mon, 06 Jul 2015 17:05:21 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.2 Technical Debt is not only a “Technical” Problem http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/#comments Mon, 06 Jul 2015 17:05:21 +0000 http://www.ontechnicaldebt.com/?p=3540 read more]]> A question that is not asked often, and less often answered, about technical debt is: who must you pay and how?

This question is vital to answer – because it also gives you an idea of who you are borrowing from when you take on technical debt. Often times technical debt analyses miss this critical part of the financial metaphor. So who are you borrowing from when you incur technical debt? The assumption is that you’re borrowing from yourself: this means that you’ve accumulated capital and borrow against your own reserves. Paying back this debt means putting funds back into your savings. This is the best way to borrow money. However, what actually happens is that future capital is placed as collateral for the loan you take when you build a tech debt ridden feature.

When code that has technical debt is released, revenue is generated that can’t be paid for yet. In this case, you aren’t borrowing from yourself because you don’t actually have the funds to spend from. Acknowledging this leads to a better understanding of the full ramifications of technical debt. The consequences of this debt don’t solely extend to the technical side of business. For example, when this code is released and provides a service that is built in a compromised way the marketing team with have to message the feature accordingly. Sales teams have to qualify leads so  that customers are not frustrated with a product that does not work as it is said to. Product management will have to understand that every new release will be expanding on a poorly built base and will be more expensive with each release. Overall, the organization will have a flimsy strategic advantage because they have a unique feature that is built in a compromised fashion – their offering will have to be qualified and enthusiasm for the product will be watered down.

When building with technical debt its effects don’t stop at the technical level. The technical results of this debt, due to quick and dirty work, means a product that is vulnerable to failure and to not performing properly. This vulnerability infects every other part of the organization.

However, technical debt is often times the only way to get ahead. Therefore, when deciding to build with technical debt there need to be clear terms set for the loan: business leaders should be aware of what debt is being taken on and a plan of action for tracking it and paying it off needs to be implemented. The reason for involving business leaders is because the problem of technical debt is not insulated from the rest of a company – in fact by borrowing from future capital it involves the organizations very ability to bring in revenue. Therefore, if  it is not explained properly to business leaders they will not understand the necessity of paying off that debt. This leads to a lack of resources set aside to refactor and restructure debt.

It’s when organizations underestimate and don’t understand technical debt that they run into trouble.

To read the full post visit here.

http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/feed/ 0
The US Navy Pays the Price for Faltering on Innovation http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/ http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/#comments Wed, 24 Jun 2015 18:11:12 +0000 http://www.ontechnicaldebt.com/?p=3526 read more]]> About two weeks ago, we posted an article on the pressures of digital transformation and the technical debt that results from trying to keep up with innovation. We’re seeing those same pressures as the US Navy Warfare Systems Command struggles to phase out its reliance on obsolete Microsoft products. The US Navy is paying Microsoft millions of dollars to support about 100,000 computers that still use Windows XP, Office 2003, and Exchange 2003.

The retention of these programs, which Microsoft hasn’t supported for years in the commercial sector, demonstrates that some organizations just can’t keep up with the rapid pace of technology change. As we mentioned in our previous post, “the transformation businesses need to undergo in order to keep up to date with current technology, combined with day-to-day processes, amounts to a mountain of technical debt that can be nearly impossible to get over.”

Technical debt can often result in security vulnerabilities and failures – which is understandably not favorable for the US Navy. This may explain why it has taken almost three years for the Navy to wean itself from these systems, which affect critical command and control systems. A Navy spokesperson stated that without the paid support from Microsoft “…vulnerabilities to these systems will be discovered, with no patches to protect the systems.”

It is clear why the Navy is hesitant to try and play catch up, in a quick and dirty way, while phasing out its legacy systems. It also illuminates the difficulties other organizations face under similar situations, when they aren’t a government agency with the funds to keep using obsolete software, and must react to their more nimble competitors.

Government agencies prefer to have a tight hold on the technologies they work with, slowing down their adoption of modern alternatives. However, keeping an obsolete system out of a concern for security is contradictory. XP is not an adequate option to protect networks from the security threats of today and paints the Navy as a bloated government organization unable to change efficiently.  Other commercial organizations do not have the same stringent compliance rules to deal with when it comes to their technologies, allowing them to change faster and prepare for future threats.

So, how do you address such a problem? It really boils down to flexibility and preparedness for change within your organization – a common factor when discussing building software that is able to adapt to technology’s certain and constantly evolving innovation. In order to avoid continually facing the hardships of replacing antiquated hardware and software, you can start creating a plan to manage innovation. This will be helpful not only by guaranteeing quicker adaptation to the improved technologies, but also in protecting your organization from failures that result from old creaky systems.

To read the full article on the Navy’s payments to Microsoft click here.

http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/feed/ 0
When Technical Debt Is Better Than Clean Code http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/ http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/#comments Mon, 22 Jun 2015 17:55:17 +0000 http://www.ontechnicaldebt.com/?p=3517 read more]]> It is often mentioned, when reading about technical debt, that taking on debt can be appropriate and even beneficial in certain situations. However, what are the criteria that can be used to define which scenario is good for technical debt and which is not? This post gives a good answer to that question. There are two times when it is appropriate to incur debt: when creating a new feature or entering a new market.

In order to decide whether or not to take on technical debt, there are four factors that should be considered:

  1. Value of early feedback
  2. Cost of debt
  3. Cost of errors
  4. Likelihood of errors

The optimal situation to incur technical debt would be one where there is a high value to early feedback, when what is being built is isolated from the rest of the system (therefore making the cost of debt low), when the cost of errors is low due to a small number of users, and when the likelihood of these errors is low. The two scenarios mentioned above consistently meet this criteria.

The first scenario is when there is an idea for feature that could present value to users – it may then be worth taking on debt to deliver this value to users. Delivering a feature early also has the added benefit of receiving quicker feedback: if the feature is a valued addition it makes sense to take the time to pay back the debt, but if the feature does not do much for the user it can be removed from the code and effectively erase the technical debt. A quick and dirty built feature is beneficial in such a case because the probability of it being kept or thrown out is unknown. Therefore, spending time from the start of development to create clean feature is not necessarily advantageous.

The second scenario where incurring technical debt is acceptable, if not helpful, would be when working to enter a new market. For example, when developing a product with a start-up company, the first round of development should be focused on producing something that helps support the business model. This means that what is being built does not need to meet the standard of release to users – there is an expectation that the product evolve overtime and large segments of the prototype may be thrown out along with its technical debt. The benefit of building something that is debt ridden, in this case, is that it can help to figure out what the product needs to do. It may not in the cleanest rendering, but it’s better to figure out problems early on than to miss them by spending too much time building a prototype that doesn’t fulfill the business model.

Ultimately, deciding to take on technical debt should be the result of knowing how clean the code can be, and whether it is worth building code that is that clean. Understanding the benefit of early feedback, the cost of debt and errors, and the likelihood of errors still makes coming to a decision on technical debt risky, but based on the realities of development. There are some areas that should not be subject to technical debt (those that are integral to operating abilities and user experience) but there are also those that benefit from being released quick and dirty.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/feed/ 0
Is DevOps Good or Bad for Technical Debt Reduction? http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/ http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/#comments Thu, 18 Jun 2015 19:30:42 +0000 http://www.ontechnicaldebt.com/?p=3510 read more]]> Continuous delivery and deployment pipelines force the clean-up of inconsistencies and holes in deployment through consistent automation. It also allows for work to happen between development, test, and production phases, which makes code easier to manage and reduces the risk of a security or operations issues. The DevOps approach can also enable the easy payment of technical debt.

DevOps allows for teams to consistently refactor in a quicker and more secure manner. The feedback cycle guarantees that the most pressing issues for the business are addressed promptly – and fixing bugs, security vulnerabilities, or usability issues can be  taken care of before the upcoming release cycle.

However, there are shortcomings to DevOps, as consistent iterative change can become erosive. As the same code gets worked on again and again, with classes and methods inflating, the structure and design of an application begins to collapse. DevOps magnifies this issue as small changes, experiments, feature and user interface work is happening in a constant cycle. The most dangerous example of this type of work is that teams often work on the code mainframe while code is still being developed – and they use conditional logic and flags to skip over parts, which are still under construction and buggy, at run time. This can become a problem if the feature is accidentally switched on before its ready to run, and it makes code more difficult to understand.  This is why the DevOps approach requires strict regulation; the constant deployment, day to day refactoring, documentation of features, and the removal of dead code presents many opportunities for mistakes.

The presence of a large number of tasks being handled at once by different teams is why DevOps lends itself well to a microservices architecture. Microservices allow for multiple teams to independently work, deploy, and refactor a certain project. It allows for each team to decide what tool or language best suits their needs. However, as more services are added, the costs of testing increase across varying languages and frameworks which also makes tracking vulnerabilities difficult. The added complexity of each service also makes switching from team to team less feasible.

The other downside of the DevOps approach is that it promotes shortsightedness in development. With constant feedback flowing in, working on fixing bugs and immediate fixes leaves bigger picture strategic problems unaddressed. Architecture and design debt grows because immediate technical debt is seen as the priority. As this strategic debt grows, developers have to work with an aging platform that slows down the ability to respond to and make changes.

When it comes to DevOps as an approach that is better suited for technical debt reduction, it is both good and bad. In order for it to be a truly successful method of development an extreme amount of discipline and foresight is needed. This is the usual conclusion reached when speaking about technical debt – detailed management of debt is a necessity in order for a system to function as needed.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/feed/ 0
The Causes Of Technical Debt Do Not Exist In A Vacuum http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/ http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/#comments Wed, 17 Jun 2015 19:22:15 +0000 http://www.ontechnicaldebt.com/?p=3504 read more]]> Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.

There are two categories of technical debt: intentional and unintentional. For either of these two types of technical debt there are usually positive short term consequences (due to early delivery) and negative long term consequences (due to a low quality standard of software). Despite this similarity between unintentional and intentional technical debt the distinction of their causes needs to be made in order to reduce the prevalence of this quality killing phenomena.

Intentional Causes of Technical Debt:

  • Time constraints placed on development
  • Source code complexity
  • Business decisions which lack technical knowledge and make communication difficult

Unintentional Causes of Technical Debt:

  • Lack of coding standards and guides
  • Junior coders with little experience and poor skills
  • Lack of planning for future developments

The long term effects of the above are longer work hours, error and bug prone code, customer dissatisfaction, and increasing source code complexity. There are several processes that can be set into motion in order to keep technical debt at bay, or to address it before the negative consequences of it reach untenable levels.

They include:

  • Refactoring
  • Bug fixing days
  • Code Reviews
  • Clear coding standards and guides
  • Communication between business, management, and developers

While up until this point, the post does a good job of delineating the common causes, effects, and resolutions of technical debt – it is missing a key factor that would lead to the successful management of technical debt in any organization. Many of the causes of technical debt outlined above are a result cultural issues.

Unrealistic time constraints, green developers, little or no coding standards, and poor communication with the management are results of a method of operation for a business. For example, developers with little experience need to trained in order to reach the standard of work that is expected and needed for the business to thrive. Notice that in this instance there are two things needed: a clear set of standards and sufficient time allotted for training. These two items by themselves are causes of technical debt. Therefore, there is a clear connection between one cause of technical debt to another, and often times one is not present on its own. If there are unrealistic deadlines in an organization there are probably also untrained workers, non-existent standards, and a lack of communication with management to solve these other problems.

No cause of technical debt exists in a vacuum – and in order to address it there needs to be a conversation on why it is occurring and an understanding of what needs to be done to deal with it. If time constraints are a serious issue in an organization because management wants quick releases – the cost of these unrealistic time frames needs to be explained. If this exchange does not occur the cycle of poor quality code and technical debt build-up will continue.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/feed/ 0
The Conflict Between Regulatory Compliance and Velocity http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/ http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/#comments Mon, 15 Jun 2015 13:52:37 +0000 http://www.ontechnicaldebt.com/?p=3496 read more]]> Regulation is a fact for every financial institution, which can be a challenge when competitive pressures are mounting –  but this is no more challenging than it is for the software that has been developed to use internally in different organizations. Technology is now the main source through which consumers and companies interact. While technology has become a game changer for many organizations, regulatory compliance has increased alongside this change. Technology, however, in the fast paced digital marketplace it operates in today, often outpaces the regulation set up for it. This requires that regulatory frameworks be able to adapt and evolve to changing technology.

It is often mentioned that the most regulated industries are those that are most vulnerable to disruption by newcomers. This is especially true for financial services where challenger banks and payment services providers have a lower compliance barrier to entry than established institutions. For them the bar is lower because of technical debt. Challengers to new institutions do not have the same burden of decades of accrued technical debt. The already established institutions have to retroactively fit in compliance measures to their technical debt burdened systems – and one of the greatest downsides of technical debt is that instilling changes into a technical debt ridden area is a very slow process.

Regulations are not always those imposed by external authorities but can also be those that have been implemented internally. Regulations do not stay static over time and many often continue to be defined as time goes on. This, therefore, requires that the process of implementing these compliance measures needs to be susceptible to change. It is then the case that when a piece of software is ready to be shipped, and fits into the regulatory framework of that moment, it may not remain within the regulatory rules further down the line. It also becomes increasingly difficult to be aware when compliance changes affect current systems, because changes to software are rarely thoroughly documented.

As compliance frameworks are increasingly granular it becomes more difficult to maintain the velocity that is needed to keep up with digital innovations. The conflict between compliance and innovation becomes a juggling act between proving that rules have been followed and reducing the lag-time as a result of the increasing levels of regulation.

As the amount of regulation increases, it becomes unfeasible to verify manually that rules are being followed. This means that compliance needs to be integrated into the very code, similar to other features and qualities. By automating compliance into software production it can be tested throughout development and can be changed due to infrastructure, application, or compliance modifications.

The larger an organization the more difficult it is to instill new automation – however, it is necessary in order to remain successful. Automation can be achieved by starting off with a small amount of work that can later be scaled for more teams and used as an example for future automation work. Ultimately, in order to be compliant, having an infrastructure that is amenable to rapid change in regulation and technology is crucial.

Read the full post here.

http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/feed/ 0
The Pressure of Digital Transformation and Subsequent Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/#comments Wed, 10 Jun 2015 19:36:42 +0000 http://www.ontechnicaldebt.com/?p=3492 read more]]> When planning 2015’s budget most companies left out new resources needed for a key generational shift: the change from a centralized technology support department into a sleek and fast digital line for business. There has been a great deal of attention given to the role of Chief Digital Officer as they are meant to lead these new digital aspects of the business in many organizations. Despite the excitement surrounding digital transformation, the majority of enterprise data, expertise in current systems, infrastructure, and operations is under the supervision of the CIO, and the CIO’s responsibilities usually encompass business/IT alignment, security, and managing the legacy portfolio. They do not include pushing through digital developments for the business.

IT departments are slowly beginning to rethink business in a digital environment. The big five IT changes that occurred 3 years ago (mobile, social, cloud, consumerization, and big data) created an unheard of amount of changes that need to be adopted at the same time. In most organizations the process of adoption is still in process, which may begin to signal that the ability to align what is achievable and what is needed might become unsustainable. The transformation businesses need to undergo in order to keep up to date with current technology, combined with a static budget and day-to-day processes, amounts to a mountain of technical debt that can be nearly impossible to get over.

Further discouraging organizations to take on large scale enterprise transformations is that the success rate of such tasks still hovers around only 30%. However, top performing companies are aiming to take on the challenge as the long term rewards in new digital technology are great. This demonstrates the difficulty that IT leaders face – digital transformation is likely to under-perform but since competitors are investing heavily in technology, the risk may like an attractive option.

When asking about the top priority for most CIOs in the upcoming year the overwhelming response is to improve applications to fit business processes better. This is not in line with a modern business’ needs for sustainability as technology has become a driving force in defining the markets leaders. Looking at the IT leaders misaligned priorities and the increasing pressure to undergo technology transitions with a stagnant and inadequate budget, there is not mass push for digital transformation by most organizations. There is not proactive engagement, from most companies, with the digital movement, as they are not willing to undergo the challenge of digital innovation.

Those that have been successful in the transition to digital are often either a top performer that invests heavily in technologies that are likely to boost growth or is an organization using financial acumen to strategically buy only the technologies needed. It is likely that those who invest too little in technology will not succeed – so there is a closing window for organizations to undergo the technology transition that is needed to allow their organizations to move forward.

Based on the above, there needs to be a change in the mindset of IT leaders on the risk of ignoring innovation for too long – along with the risks of taking on such innovation with insufficient resources – and its effects on the success of their organizations. The fear of mounting technical debt and a thin budget should be taken head on by arguing for more resources and explaining the necessity of up-to-date technology to key stakeholders.

To read the full post on digital transformation and the ticking clock for IT leaders to jump on board click here.

http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/feed/ 0
Technical Debt: The Difference Between Standing Still and Moving Forward http://www.ontechnicaldebt.com/uncategorized/technical-debt-the-difference-between-standing-still-and-moving-forward/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-the-difference-between-standing-still-and-moving-forward/#comments Thu, 04 Jun 2015 13:34:58 +0000 http://www.ontechnicaldebt.com/?p=3487 read more]]> Currently, there are many businesses whose innovation and productivity are hampered by costly and inflexible information technology. Anywhere between 4-6% of a firm’s revenue is spent on IT – a figure that has grown in recent years. This growth in the expense of IT can be attributed to neglect, poorly executed integrations, and the rapid speed of change in technology. Quantifying the cost of lost productivity and innovation is a difficult task, but Gartner estimates that the total cost of poor systems architecture, design, and development will reach $1 trillion in 2015. This is an average of $1 million per organization or, according to software analytics firm, CAST, approximately $3.61 per line of code.

This expense is called technical debt. The challenge with technical debt, for IT leaders, is that the cost of lost opportunities attributed to tech debt is not easily calculated, but the costs of attempting to modernize legacy systems are quite visible and substantial. Therefore, in order to improve performance of IT systems, IT leaders need a thorough understanding of technical debt.

The author of this post goes onto describe an experience with a mid-sized manufacturer that was spending 85% of its maintenance budget on supporting one legacy system. In this scenario integrating new applications was a risky endeavor and the constant maintenance required was taking resources away from automation activities that would stimulate growth. The old system at the firm mentioned was successfully phased out, and a more modern and efficient one took its place. However, the ultimate focus should not be on the success of replacing the old system, but on why the old system was so riddled with technical debt.

The difficulty of dealing with technical debt is leveraging the resources available to support current processes and capabilities with the existing deteriorating code, while also deciding when and how to transition old systems out to support new objectives. An effective analogy would be to compare an old legacy system to an old beat up car. The owner of this car knows that it would be cheaper in the long run to replace the car with a more modern and efficient one, but may not be able to do so because they don’t have enough for the down payment or can’t go a day without the transportation. They are subsequently stuck trying to keep the old car running. However, this analogy does not demonstrate well the value of abandoning the old system. The difference between an poorly running legacy system and a modern fully integrated one is greater than the difference between an old car and a new car. This is because, ultimately, either car will achieve its goal of getting its owner to a destination. With an old technical debt ridden legacy system and new efficient system, the difference in outcomes are supremely different. A new top-notch system can deliver opportunities for innovation that the older system would inhibit.

Eliminating the source of technical debt (the old legacy system) is not as simple as hiring developers to rebuild the infrastructure; this does not keep future technical debt from rearing its head again in the future. In order to proceed with handling technical debt and its consequences, the following steps need to be taken:

  • Calculate existing technical debt: this can be done by comparing the capabilities of the current software in place to industry-leading versions.
  • Determine the organization’s goals: to what extent do business activities currently rely on the legacy system in place, and what functionality will be needed in the future system.
  • Identify and prioritize the areas that require the most remediation.
  • Measure and track the progress of this process at the senior level.

It is necessary to be aware that even after updating the systems in place the threat of adding on technical debt again is still very much present. This requires vigilance of the efficiency of IT operations.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/technical-debt-the-difference-between-standing-still-and-moving-forward/feed/ 0
The Economics of Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-economics-of-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-economics-of-technical-debt/#comments Tue, 02 Jun 2015 18:52:30 +0000 http://www.ontechnicaldebt.com/?p=3480 read more]]> Ward Cunningham introduced the technical debt metaphor as a method to highlight the potential for higher costs in product development from postponing some work on software in order to release other parts faster. The comparison between financial debt and the term technical debt was meant to demonstrate the eventual need to complete postponed work and repay the principal of delaying it. Technical debt also alludes to the possibility that interest costs, associated to postponed work, can become so high that they impede any other important work from being done on a project.  For these reasons, technical debt is a useful concept – as it clearly communicates the danger of postponing work. However, metaphors often conflate two comparable situations, to two identical treatments of similar situations. This can be avoided in the financial debt/technical debt coupling, by using the financial metaphor to identify the economic forces behind technical debt.

In the simplest explanation of financial debt, where all of the principal is repaid at the end of a loan period  and interest is paid regularly until the principal is returned, there are three economic consequences to consider.

  1. The immediate benefit of access to the principal, has certain (known) magnitude and timing.
  2. The obligation to pay back the full principal at a specific time is of certain magnitude of timing.
  3. The future obligation to return 100%  of the principal at a specific time is of certain timing and magnitude.

The summation of these consequences is that financial debt has very specific and known consequences – everything is calculated with certainty when this type of debt is taken on.

If the similarities between financial debt and technical debt are extended, there also three economic consequences to take into account. However, these consequences have different results than those of financial debt.

  1. The immediate benefit of postponing the expense of development effort may result in savings of both expenses and cycle time; but the magnitude and timing of these benefits is uncertain.
  2. The ongoing obligation to pay economic rent on deferred work is also of uncertain magnitude and timing. It can range from positive or negative magnitude and has volatile timing.
  3. There is also a highly uncertain future burden to repay the postponement of work – the amount and timing of this burden is unstable.

As with financial debt, it is only economically sound to take on technical debt when the cost of the burden incurred is lower than the benefits gained by deferring work. In order to understand the economics of technical debt there must be a keen awareness of the costs that come into play and the uncertain nature of these costs.

This post delineates the economics behind technical debt through a variety of calculations.

First Calculation

The case presented, for calculating the costs of technical debt, is whether to release a product with technical debt immediately, or spend 2 months and $40,000 to release a debt free product. To begin this process, assume that there is $40,000 of deferred development expenses in a year 1, and $60,000 spent per year in maintenance costs for this product. If then, the work is deferred until year 5 and paid back at twice the cost of the original effort ($40,000 x 2), an attempt to save $40,000 in development costs actually ends up costing $340,000.

This may seem like a cogent analysis of the costs of technical debt but there is a major factor that is missing in the calculation.

Second Calculation

In the first iteration of analysis, the missing element in the calculation was the cost of delaying the release of the product for two months. Cost of delay (COD) is a quantifiable measure and pertains to both deferred and non-deferred work. So in addition to costs set up in the first round of calculation (deferred development expenses, maintenance costs, and payment of deferred work) the COD on non deferred work, at $250,000 per month, needs to be included. Deferred work, in this case, comprises of 3% of the product value and 3% of the total cost of delay ($250,000 x 12 months x 3%) and therefore amounts to $90,000. The delivery of non deferred work, two months early, at 97% of the product value ends up saving $485,000 ($250,000 x 2 months x 97%). Given these numbers, the result is more informative on the costs of delaying work – delaying the delivery of the extra 3% of the product value incurs no net costs for 3 years. This is until the savings from releasing 2 months early are spent, and at the 5 year mark the deferral of work, and its eventual repayment, costs $305,000.

While this calculation is able to capture the benefits of postponing work, it does lack a recognition of the uncertainty of the costs related to postponed work.

Third Calculation

The assumption that some of these costs are uncertain should be employed when calculating the debt incurred from deferred work, and the calculations should be adjusted to take into account the likelihood of these costs. Therefore, in this example, all the costs associated with deferred work will be weighted at a 50% probability of occurrence. When taking into account the uncertain nature of costs, the results of deferring work can be justified for a full 5 years, although the cumulative benefit of the postponed work decreases every year. This result is based on the other calculations as 3% of the product value is being deferred at 50% rate of probability, meaning that instead of $90,000 COD on postponed work, it will be $45,000. This probability also applies to maintenance costs on deferred work lowering costs from $60,000 to $30,000.

These calculations should not be interpreted as a universal rule for technical debt calculations. In another case, where the deferred work accounts for a higher percentage of product value, or the probability of payment is higher – the benefits of postponing work may not be as lengthy or as strong as in the example presented above.

As demonstrated by the variance in the calculations above, depending on what is considered when analyzing a decision to take on technical debt, there are many concerns that need to be implemented and taken into consideration:

  • Using an economic frame that treats the decision to incur technical debt as an economic choice will help guide the process. Taking on technical debt should not be seen as a philosophical choice but as one that shrewdly weighs cost and benefit.
  • Focus on net benefits – sometimes leaving out a feature can cripple a system, and other parts of the system can begin to increase in cost. A close look at the work chosen to be deferred and how it will affect the rest of the system is necessary.
  • Feedback is staple in technical debt management, early on in a project it can significantly help reduce risk. Risk reduction can often become more important to consider than savings or expenses.
  • There is a common tendency to overestimate the benefit or releasing debt free product. This solution always seems like the better option when it is not being executed, but when practiced it can be different. Going through with analysis of the options ensures that a discount value be placed on the debt free solution.
  • Recognize the dependency on time that the economic rent associated with postponed work entails. For example, there is a targeted 30% performance advantage in a project – but earlier on in the life cycle it is possible to attain a 20% performance edge. It could be economically beneficial to take a hold of the 20% advantage and then move on to achieve the original 30% goal before competitors reach parity. The period of time when there is a sufficient performance advantage over competitors can be considered rent free.  Therefore exploiting that time to retire debt before interest charges set in can be a good strategy.
  • Consider that there are situations where there may not be rent on deferring work: when nobody cares about a feature there is no value in delivering it early, and no cost when it is not available.
  • Acknowledge the times when rent can be negative; this is when the feature being left out may actually cost more than the benefit received by it. For example, deciding whether to use a piece of open source software immediately vs. developing a superior solution by using customized code. The open source option may produce less utility than a customized solution, but it may save significantly on support costs. Therefore, when savings on support exceed the forfeited utility, deferring work and opting for open source produces negative rent.
  • Evaluate the need to repay the principal carefully – often times it will be cheaper to pay in the future because requirements will be better defined. However, there are instances where the cost increases drastically the more time is spent waiting to pay the principal back.
  • Don’t assume that doing work immediately will prevent work from having to be done later. There may be a scenario where the preemptive effort did not prevent further effort, and the work is paid for twice.
  • Reduction in batch size improves the economics of deferral. For example, if 50% of the work is postponed for a later date and the other 50% is delivered, the cost of deferral will be high.
  • Be aware of the biases that arise when referring to deferred work as technical debt – technical debt as a term often causes the costs of deferral to be overestimated because of the negative connotations associated with debt. Calling it a deferral instead of debt increases the relation of the metaphor to finance, because it is a term that is also used in the industry and is devoid of a positive or negative connotation.

The goal of this post is not to discredit the utility of technical debt as a metaphor, but serves to highlight that reasoning based purely on a metaphorical idea can lead to poor economic decisions. Adding some math, and heeding the use of the term technical debt due to bias, can benefit a project. This should be especially beneficial considering that stakeholders in a project respond well to and rely on economics in making decisions. Framing choices in economic terms can benefit a project by communicating options in a language which decision makers understand.

To read this full post and see the full rendition of the calculations mentioned above visit here.

http://www.ontechnicaldebt.com/uncategorized/the-economics-of-technical-debt/feed/ 0
The Bunny Theory of Code: Keeping Poor Quality Code from Multiplying http://www.ontechnicaldebt.com/blog/the-bunny-theory-of-code-keeping-poor-quality-code-from-multiplying/ http://www.ontechnicaldebt.com/blog/the-bunny-theory-of-code-keeping-poor-quality-code-from-multiplying/#comments Wed, 27 May 2015 20:50:55 +0000 http://www.ontechnicaldebt.com/?p=3469 read more]]> This is a post that discusses a type of technical debt that arises when bad quality code finds it way into the source control. As with other types of technical debt, the bunny theory of code described in this post, multiplies itself until it is found in all areas of the source code.

A high value should be placed on what code ends up in the source control, because once code gets checked in, it is likely that it get copied and used again. The bunny theory of code, is basically this: that when close attention is not paid to code it multiplies. This in its self is not qualified as either good or bad – because all code functions in this way. But when the code being copied is not good it begins to pose a serious problem. The reason the bunny theory of code holds true for all code is because of the method most software engineers work . They rarely begin writing code from a blank file but instead copy code that is similar to what they want and modify it for their purpose. This is again, is neither good nor bad, but simply an effective way of writing code efficiently.

When looking for existing code to copy the most common source is the source code repository, which provides the false promise of quality of the code that it contains. It makes writing code simple as an engineer only has to find code they can work with, copy it, and modify it. However, there is no guarantee of the quality of code within the source code repository.

For example, in this post the author mentions a personal experience where he delved into the source control and found a piece of code that worked with his project at hand and moved on to copy it. However, he realized that the code contained a comment that stated to not copy the code as it had not been written properly and should only exist in that once instance. The original engineer was aware that the code written was not well done and had left the problem for someone else to solve. While, on the one hand, this warning is a good measure to take to  ensure that the poorly written code was not used in further situations, on the other hand, it left the code in the source code repository for others to use it.

This is the issue when bad code is checked into the source control – it increases the likelihood of it being used again. This can happen over and over again until the bad code infiltrates all parts of the repository and is extremely difficult to remove. This problem becomes more pervasive the larger the amount of people adding to the repository grows. Therefore, it is extremely important to ensure that what is placed in the source control is only of high quality.

In order to maintain a clean code base, efforts should be made to prevent the first piece of of bad code from getting into the source control. Enforcing or disallowing patterns through automation is a good way to start. The more that can be automated and blocked from entering the source code repository the better. However, there are certain patterns that are difficult to identify through automation. This is where code reviews are necessary; a human eye will be able to discern what belongs and what does not.

Through automation, code reviews, and code workshops keeping everyone in the loop on what is expected to be in the source control is feasible. While this seem like more work than it is worth – not doing anything will most likely lead to a mess of code. Given the way in which software engineers write code, it is necessary to ensure that the code being copied from the repository meets a set standard and is acceptable to be used over and over again.

To read this full post click here.

http://www.ontechnicaldebt.com/blog/the-bunny-theory-of-code-keeping-poor-quality-code-from-multiplying/feed/ 0