On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 02 Apr 2015 09:00:34 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.4 Microservice Architectures and Cutting Down Technical Debt http://www.ontechnicaldebt.com/software-quality-technical-debt/microservice-architectures-and-cutting-down-technical-debt/ http://www.ontechnicaldebt.com/software-quality-technical-debt/microservice-architectures-and-cutting-down-technical-debt/#comments Thu, 02 Apr 2015 09:00:34 +0000 http://www.ontechnicaldebt.com/?p=3412 read more]]> This post seeks to respond to a question on how to  restructure a poorly formulated monolith, and whether reformulating it into another poorly formulated set of microservices is ever the correct answer. This question is used to highlight the idea that a team which is incapable of creating a well structured monolith probably won’t be able to solve this problem by distributing it differently. However, a team dealing with a “big ball of mud” might find solace in the principles behind microservice architectures.

One way to manage a messy monolith is to increase the probability that everyone working on the codebase understand what is going on within it. This requires to things: consistency and replaceability. Consistency means that assumptions can be made on unknown parts of the codebase due to how other parts of the codebase work, while replaceability has to do with the ability to get rid of certain parts of the code to replace it with something better. A strategy that applies a single responsibility framework at the large-scale level of the codebase allows a more systematic and feasible approach to getting rid of low-level technical debt. Breaking up a monolith is beneficial because components that share fewer dependencies and have separate release cycles allow for an increased amount of flexibility structuring applications and the teams that develop them.

Microservices allow for “localized technical debt” – which is mentally easier to tackle than one lump sum. Switching to microservices also keeps a potential rewrite of the legacy system from being a huge and daunting affair and may improve getting to a state where incremental improvements are the norm.

To read this full post go to: https://genehughson.wordpress.com/2015/03/28/microservice-principles-technical-debt-and-legacy-systems/

]]>
http://www.ontechnicaldebt.com/software-quality-technical-debt/microservice-architectures-and-cutting-down-technical-debt/feed/ 0
Reducing Technical Debt to Scale-up Productivity http://www.ontechnicaldebt.com/blog/reducing-technical-debt-to-scale-up-productivity/ http://www.ontechnicaldebt.com/blog/reducing-technical-debt-to-scale-up-productivity/#comments Wed, 01 Apr 2015 09:00:03 +0000 http://www.ontechnicaldebt.com/?p=3407 read more]]> In this post the question “how to create value for businesses at a time when labour arbitrage in the outsourcing industry has plummeted?” is looked into and one of the strategies that has been employed is to reduce technical debt. Business productivity is directly linked to application software health, which in turn depends on code quality. The structural quality of code is determined not only by the computing ability of an application but also from the architecture details and code construction methods – the ability to stand up against crashes and data corruption is thus related to the quality of the code base. The level of technical debt in the code base affect these items and therefore is extremely important to cost and risk management in any organization.

CAST, a software analysis and measurement company, estimated that technical debt costs and approximate $3.60 per line of code and that for an average sized application the cost of technical debt would be over one million USD. Business users in the digital era desire clean and simple designs that require little refactoring in the future. This new outlook is largely a result of an evolving model of outsourcing and current objectives focused on scaling up productivity. 

Another key factor in application development and maintenance that helps scaling up productivity is designing delivery models based on tangible business outcomes, such as: “improved enrolment of a healthcare plan” and “reduced call waiting times in a call centre”. The idea of co-creation, now prevalent in many organizations, is bolstered by the idea of sharing both risk and rewards in application development methodologies. CIOS should begin to integrate these strategies into their business approaches in order to deliver more value to their customers in key IT-driven markets.

To read this full post go to: http://www.virtusa.com/blog/2015/02/cios-look-reduce-technical-debt-scale-productivity/

]]>
http://www.ontechnicaldebt.com/blog/reducing-technical-debt-to-scale-up-productivity/feed/ 0
Technical Debt vs. Product Design Debt http://www.ontechnicaldebt.com/uncategorized/technical-debt-vs-product-design-debt/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-vs-product-design-debt/#comments Tue, 31 Mar 2015 09:15:03 +0000 http://www.ontechnicaldebt.com/?p=3403 read more]]> This post speaks about two different types of development debt that are caused by various agile practices or incrementalism. The outcome of these practices are best exemplified in sayings like: “deploy early and often”, “fail fast”, and “ship and iterate”. Although this method of development is lauded, a bit into the product cycle there will be some incomplete projects, a  poorly scaled infrastructure, and messy code to be refactored left as a consequence. Most engineers know that this will be the result of most agile practices and promote continual refactoring to keep technical debt under control. However, technical debt is not the only result of these practices – product design debt.

Product design debt is the result of sticking a bunch of new features on, for example, the homepage of your website and centre the design of the page around these features. After some time of scaling this design as far as possible until the design must be refactored. Product design debt unlike technical debt impacts the user experience rather than the underlying technology. However, the same reasons for which technical debt is incurred can be applied to product design debt; adding new features and not doing it the right way the first time because it is not sure that it will be kept or work in the long run. As the product experience grows, the original strategy of simply adding tabs, buttons, or links to a homepage stops scaling. This means that the user experience becomes messy and poor the more things are added on without reorganizing the site. However,reorganizing the whole site can be a daunting task but is necessary.

It is often hard to point out the true costs of product design debt because each incremental change does not change much in the user experience – but after enough changes the design of the product begins to look sloppy and stops being user friendly. In a startup environment where there is one person in charge of such innovations to the user experience they are more able to reformulate the design debt issues; contrastingly in large organizations where there is a lot of competition between teams more features begin to be added and end up amounting a high amount of clutter on certain user experiences.

Ultimately, certain products like social networking sites, news portals that want to unify media from several sources, games that have many features, retail sites that provide lots of products categories and SKU numbers, and classified sites are the ones most susceptible to product design debt. Keeping a keen eye out for this source of debt is extremely important because it is directly related to consumer satisfaction, and is also related to another important development tool: technical debt.

To read the full post go to: http://andrewchen.co/product-design-debt-versus-technical-debt/

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-vs-product-design-debt/feed/ 0
Technical Debt: A Framework for Product Managers http://www.ontechnicaldebt.com/blog/technical-debt-a-framework-for-product-managers/ http://www.ontechnicaldebt.com/blog/technical-debt-a-framework-for-product-managers/#comments Thu, 26 Mar 2015 09:21:17 +0000 http://www.ontechnicaldebt.com/?p=3400 read more]]> Here is a post that discusses why and how product managers must access and manage technical debt. Technical debt often first considered as solely theory, until the pressures of time and customer desires create the need for compromise and quick and dirty shortcuts. Once the results of these pressures start to build up and create an amount of technical debt that demands a solution.

Technical debt is incurred when trade offs are taken in order to have shorter time-to-market and capital preservation. But after some time of building on the amount of technical debt in an organization it limits productivity and increases the amount of time needed to implement new features. Product managers are meant to balance out the short and long terms gains of ever decision on a product, but they should also keep track of the technical debt built into the codebase. Introducing a framework that anticipates any inadvertent debt that could occur and manage it as a roadmap item.

Fowler, famously, categorizes technical debt as reckless vs. prudent and deliberate vs. inadvertent – while this explains how dept is taken on it doesn’t demonstrate what or where this debt is added. This post further asses the risks of technical debt in a detailed chart of deliberately added debt:

Screen Shot 2015-03-25 at 5.05.09 PM

 

By using the framework above as a checklist for new feature development, even nontechnical product managers can assess the risks and damage of accumulating technical debt. Including these six parameters as flags the requirements management tool against every feature and defect would be the simplest method to guarantees that debt is thought about and decided by the team whether it is worth  paying back. Using this to report on areas that have stored technical debt is a good use of this method.

Quantifying technical debt is a good practice because although there is no benchmark for acceptable technical debt determining how debt has changed over time can help any organization.

To read the full post go to: http://www.prasadgupte.com/blog/technical-debt-assessment-framework-product-managers/?utm_content=buffer0b87d&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-a-framework-for-product-managers/feed/ 0
Technical Debt – It Is Not Inevitable http://www.ontechnicaldebt.com/blog/technical-debt-it-is-not-inevitable/ http://www.ontechnicaldebt.com/blog/technical-debt-it-is-not-inevitable/#comments Wed, 25 Mar 2015 09:10:39 +0000 http://www.ontechnicaldebt.com/?p=3397 read more]]> This post beings with an interesting statement: that in a start up environment technical debt often feels inevitable. Technical debt can be seen as a function of moving fast, minimum variable products (MVP), prototypes, agile practices, and of releasing the product to market as soon as possible.

The idea of using a minimum variable product to justify cutting down thinking time and taking short cuts on testing, allows teams to release a product that is barely complete. It does get the feature live quickly and will pass unit tests now, but what isn’t considered is how it will work in future iterations. The pressure to prove that a product is fit for market often makes these minimum variable products the foundation for huge long-living codebases. When the MVP is  first developed, there are intentions to return and refactor the barely functional code – however under the pressures to deliver innovation these intentions are required and more and more code is built upon this unstable feature. Avoiding this cycle would be the most beneficial for a start up in its early stages.

There are several downsides to technical debt are many. When technical debt is first incurred it does help cut release time down, but only in the first few iterations. After some time your team will have to keep returning to old code in order to rework certain items, which ends up adding time to new feature development. Over time, the result of all this reworking will be spaghetti code: “sourcecode that has complex and tangled control structure”. This overly complicates the codebase until there reaches a point where there are areas in the codebase that no one wants to work on. This adds an extra step in the development process where the quality of certain areas of code need to be taken into consideration. The stability of certain foundations need to be determined before any new work can be done to build a new feature. This is a time-consuming process and also error-prone because finding the foundations that are less stable is difficult. It will also mean that engineers will be less willing to build new things, as they will also have to worry about refactoring and the bugs that can emerge from changing things within the codebase.

Minimizing technical debt does not mean erasing all technical debt from the codebase, but it does mean avoiding deliberate or quick and dirty shortcuts. This means building to the best knowledge available at the moment, and if later on issues arise that need to be attended to there is a stable foundation to work with. However, knowing as much as possible before building is extremely helpful. By discussing issues with peers and holding whiteboard sessions to explain problems and solutions a more sustainable way to build will emerge. Therefore, beginning with the mindset of minimizing technical will set up the basis for a cleaner and more stable codebase.

To read the full post go to: https://medium.com/@benji/technical-debt-it-doesn-t-have-to-be-this-way-5e03dfc2e53

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-it-is-not-inevitable/feed/ 0
Technical Debt: What It Is, and What It Means for Your Web Project http://www.ontechnicaldebt.com/uncategorized/technical-debt-what-it-is-and-what-it-means-for-your-web-project/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-what-it-is-and-what-it-means-for-your-web-project/#comments Mon, 23 Mar 2015 20:15:59 +0000 http://www.ontechnicaldebt.com/?p=3392 read more]]> If any piece of software is seen as an investment for your business than it is best to not think about driving costs down to a base minimum. It is better to focus on the return that the money and time invested can generate. This sort of financial metaphor is helpful to understanding technical debt. This post defines technical debt as the choices in your software that create work that is just  ‘good enough’ and how these choices will impact the future needs of your business. A distinction is made that unlike real debt, technical debt will never need to be paid back if no future changes will be made to your software. This is part of the reason why some software systems are decades old – no one wants to pay down the debt by improving it. However, when improvements need to be made several things will occur:

  • Inaccurate time and cost estimates will be made by new developers who are not aware of the level of technical debt in the system
  • Developers who are aware of the effects of technical debt will inform you that changes or innovation will take much more time and be more complex to complete than expected
  • Developers may start to suggest starting from scratch for reasons that may be difficult to understand

Although it is almost impossible to avoid technical debt completely there are steps that can be taken to prevent taking on unnecessary debt. Firstly, and what may seem like an obvious step, is to hire developers who are good at knowing what is the right thing to do in a given circumstance and won’t take dumb shortcuts. Another tip would be to build software with the future in mind – this may be difficult as there can be unexpected needs that come in the future but there are certain things that can be prepared for. Also, staying away from quick fixes by insisting that developers do things the right way from the start which will minimize the chances of unnecessary technical debt. Finally, reinvesting in your software is important so that your infrastructure doesn’t get old and susceptible to breakages. To read the rest of this post go to: http://wpbusinesstips.com/2015/03/technical-debt-what-it-is-and-what-it-means-for-your-web-project/

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-what-it-is-and-what-it-means-for-your-web-project/feed/ 0
Technical Embezzlement: Technical Debt Without Agreement http://www.ontechnicaldebt.com/uncategorized/technical-embezzlement-technical-debt-without-agreement/ http://www.ontechnicaldebt.com/uncategorized/technical-embezzlement-technical-debt-without-agreement/#comments Tue, 17 Mar 2015 09:00:47 +0000 http://www.ontechnicaldebt.com/?p=3388 read more]]> This post describes a new term related to technical debt: technical embezzlement. In order to further define the term, building off of technical debt is necessary. Technical debt refers to the eventual consequences of poor system design, architecture, or development in a codebase. If this debt is not repaid it begins to accumulate interest and makes future innovation and maintenance more difficult. An atmosphere where technical debt can often persist is in an organization where management places too many constraints on time, people, or scope constraints on the development team. These constraints are often set in place to speed up time to market delivery but then push teams to trade technical debt for shorter delivery time. These sort of trade offs can be good for an organization when management is aware that it is happening and their developers are trusted – however, when this is occurring and management is unaware technical embezzlement is the result.

Technical embezzlement is defined in this post as: “knowingly taking on technical debt and then knowingly withholding that fact from your stakeholders”. Technical embezzlement can be a result of an organization that has a fear based culture where managers are seen as punishing those who bring up being overly constrained, or management doesn’t accept or acknowledge technical debt as the result of these constraints. In these situations technical debt remains at the team level but technical embezzlement is an organizational issue.

As well as the aforementioned reasons for technical embezzlement the desire to shipping out new features can also be a cause. Fora developer releasing a new feature can be exciting but can lead to taking short cuts when building the feature and moving on to the next new thing. This, although done without bad intentions, is technical embezzlement as the developer knows that they are short changing their stakeholder and customer. Being aware of such an inclination is necessary within any organization and requires vigilance and automated guardrails like test-driven development, pair programming, and code analysis tools.

Another situation in which technical embezzlement occurs is when there is a misaligned rewards system within an organization. For example, an organization that wants to release sustainable code but only rewards shipment of features without a reward for quality has actually created a system that rewards trading off technical debt for quality without realizing it.

The goal of this post is to create an awareness for taking on technical debt without agreeing upon it before hand by giving it a name: technical embezzlement.

To read the full post go here: http://www.curiousbeing.com/new-blog/2015/3/15/technical-embezzlement-opaquely-creating-technical-debt

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-embezzlement-technical-debt-without-agreement/feed/ 0
Technical Debt: A Repayment Plan http://www.ontechnicaldebt.com/uncategorized/technical-debt-a-repayment-plan/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-a-repayment-plan/#comments Fri, 13 Mar 2015 09:01:27 +0000 http://www.ontechnicaldebt.com/?p=3379 read more]]> Technical debt is usually incurred when a team consciously makes the decision to put in less than optimal technical work for the short term gain of their project. For example, the team may not put in depth automated tests into their code in order to get the product to market sooner. The key to technical debt is that it was a decision that was knowingly taken. This means that many things that are often listed under technical debt are not actually so; a decision that was taken that later turned out to be wrong is not technical debt. This distinction is important, because knowing what exactly to define as technical debt is necessary before taking steps to eliminate it. Although it is still important to still recognize the effect of unintentional debt in the codebase it is not possible to plan in advance how to address these effects as it is with technical debt.

As technical debt derives itself from a financial term it is important to extend the metaphor in order to manage it. When borrowing from a bank it is unlikely that the bank would approve the loan without a date and plan  for repayment; therefore, just like financial debt when taking on technical debt when and how to repay the debt needs to be established. Returning to the example of forgone automated tests in order to get the product to market sooner, it needs to be stated that the code will be returned to in order to add the tests at some point in the future. However, simply stating that tests need to be added later does not help stakeholders understand the importance of incurring technical debt. In order to communicate the weight of such a decision, explaining the costs of waiting to add the tests later and the increasing level of difficulty in retrofitting tests to existing code is necessary. The later point is of great importance as it signifies to the interest rates on the debt incurred.

After discussing options for repayment it is likely that stakeholders and the team will realize that the decision is not simply between adding tests later or delivering without testing. It is possible that other options suit the project at hand better than either extreme just mentioned. It could be that creating tests for simpler parts of the code and holding on tests for the more complicated aspects is the best option for quick release, or applying tests to the more complex code and waiting to add tests for the simpler code is the most appropriate mode of action. Whichever route the team decides to go, these options would not have even been developed had the discussion on technical debt not occurred.

Following the decision of how to repay the technical debt incurred, a date should be set for when to repay the debt. It is best to repay technical debt soon after it is incurred and best to schedule repayment at the time it is incurred. Therefore, if working in a sprint-drive schedule putting repayment in the calendar for the next sprint forces the team to repay it when often repayment can be pushed aside because of a perceived lack of time.

In order to further develop the financial metaphor of technical debt it is necessary to draw out the situation that occurs when a team defaults on their debt. Continuing with the automated testing example, if it is decided not pay back the debt incurred by not adding testing at the time of release it will become increasingly more difficult and expense to add functionality on to existing code. There will also be a heightened appearance of bugs within the product which will lower customers perception of quality of the product and the team will be less able to respond to changes in the marketplace as there will be parts of the product that are too difficult to change or too risky to address.

While the majority of this article addresses payment plans for intentional technical debt, it does recommend planning for bit rot (un-intentional technical debt). Because it is unknown what exact tasks will arise as a result of bit rot, it can be helpful to create a buffer in the schedule in order to create time for possible problems that need to be addressed in the future.

After having discussed the actual effects of incurring technical debt, this article addresses how to make certain that the debt gets paid back. Budgeting by points for certain tasks on each sprint can be very helpful. In this point, 50 points is allocated for each sprint – therefore, dividing the sprint into 10 points paying pack technical debt, 5 for basic code maintenance, and 35 points for new development. By budgeting the project in such a way it ensures that new development does not come at a cost mounting technical debt.

This point emphasizes the relationship between technical debt and financial debt as a way to better the understanding of when to induce technical debt for the improvement of a project. Also, by planning out a budget in increases an awareness of when technical debt is manageable and when it is reaching dangerous levels.

To read the full post go here: http://www.infoq.com/articles/tech-debt-repayment?utm_source=infoqEmail&utm_medium=WeeklyNL_EditorialContentProcessPractices&utm_campaign=02242015news

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-a-repayment-plan/feed/ 0
Is Tracking Technical Debt A Waste Of Time? http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/ http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/#comments Thu, 26 Feb 2015 09:00:02 +0000 http://www.ontechnicaldebt.com/?p=3377 read more]]> Tracking technical debt in the development backlog is meant to make the costs and risks of the technical debt taken on visible; prioritizing debt payments with other work is supposed to ensure that the payments get made. This post argues that tracking debt is not worth it.

These are the reasons listed:

Some code often isn’t worth the worry – fussy coding style issues, poor variable or method naming, methods that are too big, or other inconsistencies do not need to be tracked in the backlog, They can be taken care of with a day-to-day refactoring effort – the next time you come upon the code fix it. It doesn’t cost much and if left alone the consequences aren’t debilitating. Out of date open source code or third party or third party software can be very bad leading to exploitable security vulnerabilities. Therefore, these issues shouldn’t even reach the backlog but should be fixed right away. Everything else, like software that has been updated with some bugs fixed isn’t high priority, and updating for the sake of doing so can often break other things that are needed.

The most frightening type of debt is the debt that may not even be known about so it can’t be added to the backlog. When someone more experienced joins the team suddenly this debt can suddenly be exposed. Until a change, like this, occurs this debt keep on adding up silently. Tracking debt, thus, serves no purpose for the most dangerous type of debt. Another example would be when there is debt too big to deal with effectively. Debt that was taken on early by making the wrong decisions – the wrong architecture, language, or framework were chosen at some point and now it can’t just be resolved by refactoring. Either it needs to be dealt with as is in the best way possible or it must be taken down and built up from scratch. Tracking such a kind of debt in the backlog is pointless.

Technical debt that can be handled responsibly is debt that was taken on consciously. Short cuts taken to get quicker feedback have a good chance of being rewritten or thrown out so there is not much concern about getting it right the first time – this is strategic debt. Or if there wasn’t time to write code properly the first time so quick and dirty code is used. If it is not paid down soon it is often forgotten about and loses priority to other more present and pressing issues. It may even have been paid down without you knowing it, someone else saw that it was no longer needed and deleted it or it refactors it while making another change. The code may not even be present or in use anymore and the debt taken on is still in the development backlog.

Tracking code in the backlog seems to be the responsible option and is often recommended in other posts on how to manage technical debt. However, the technical debt that has been tracked in the backlog will never be a fully accurate picture of the debt that is actually present in the system due to unknown and undiscovered debt that has yet to rear its head. Tracking technical debt in the backlog can also be a waste of time because often times the work listed doesn’t get done. The only debt worth tracking is the debt that everyone on the team has agreed is worth tackling and paying  off. It is more practical to spend time refactoring than loading the backlog with work that might not get done.

To read the full post go to: http://java.dzone.com/articles/dont-waste-time-tracking

]]>
http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/feed/ 0
How To Calculate Technical Debt: A Top-Down Approach http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/ http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/#comments Wed, 25 Feb 2015 09:00:09 +0000 http://www.ontechnicaldebt.com/?p=3366 read more]]> As business leaders become more involved with IT investment decisions many CIOs have found it more difficult to receive funding for maintenance of applications and infrastructure. The result of this is that technical debt has become an even more useful term to explain to business stakeholders the importance of IT maintenance investments. This post goes into detail on how to calculate technical debt.

Technical debt is the accumulated costs built up within an organization due to poor coding techniques, trading off between quality and time, and using suboptimal standards. The swap for short term advantages can lead to serious issues in the long term such as: application outages, security vulnerabilities, and increased maintenance costs. Technical debt began as a term referring to quick and dirty practices but has been extended to cover issues with architecture, infrastructure, integration, and processes. CIOs are now trying to identify how to calculate its actual costs and the benefits of paying down technical debt in order to justify core renewal projects, to increase maintenance budgets, or to identify the most pressing issues for maintenance work.

The procedures for measuring code quality have become more “advanced and quantitative than the techniques typically used for measuring the technical debt associated with IT infrastructure, architecture, integration, and processes” –  in the latter areas mentioned, CIOs can achieve directionally accurate estimates of the cost of technical debt.

Before beginning to evaluate the levels of technical debt within an organization, the CIO should decide what the goals of this evaluation is; for example, if the CIO is looking to replace a 40 year old system not ever small defect within the system needs to recorded for his/her use. What should be calculated in this case is how much the system costs while running and how much would be saved once they system is retired. On the contrary, a CIO who wants to fix a system will need to identify problems, the severity of these problems, and the cost to fix them.

In order to calculate code quality debt in relation to things like claims processing or trading platform using a code-scanning tool can be a good first step. These tools often identify quality, security, and performance defects within an application and evaluate the amount of effort needed to resolve such issues. Organizations should, therefore, assess the tools available to see which meet their needs accurately. After identifying the issues that comprise the code quality debt, CIOs can calculate the costs associated with these issues, the costs to maintain them as they are, and the possible costs of debt reaching levels of business disruption. After these costs and potential costs are determined the costs needed to pay down that debt must also be assessed.

The method outlined above is a top-down approach of calculating technical debt that is more subjective than a bottom-up approach the relies more on benchmarks, estimates, and proxies. Calculating technical debt, especially from the bottom-up approach of an entire app portfolio, is a significant project to take on that could take several months to undertake. In comparison, a “bottom-up analysis of a single system or a small set of systems, or a top-down estimate of infrastructure technical debt take considerably less time”. Using such analysis allows to prioritize those areas that present the greatest risk of business disruption or areas that cost the most to carry.

To read the full post go to: http://deloitte.wsj.com/cio/2015/01/21/how-to-calculate-technical-debt/

]]>
http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/feed/ 0