On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 26 Mar 2015 09:21:17 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.3 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
How DevOps Can Cut Innovation-Crushing Technical Debt http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/ http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/#comments Mon, 23 Feb 2015 10:30:42 +0000 http://www.ontechnicaldebt.com/?p=3367 read more]]> In this post, technical debt management is looked at from a DevOps approach. Technical debt is defined here, as the price organizations pay when releasing poorly designed code. Companies that collect a large amount of technical debt are in risk of running into a situation where any innovation takes a backseat to putting out fires. Organizationally, the main blame is on the developers and architects; as defects that go through production cost about 100 times more to fix than in the early stages of development. As developers move on to other projects and their priorities shift, defects become harder to fix and the interest on debt increases. Now that there is an increase in business pressure to deliver quickly on innovations how can technical debt build up be avoided?

Agile practices become helpful to look for answers on how to avoid mounting technical debt:

  1. Avoid bad spending habits – if there are constant delays in release and deployment of a project it can be easy to put off necessary work, such as code optimization, until there is time later to fix it. To avoid habits like this the condition that causes them needs to be stopped. Testing earlier in the software lifecycle and automated deployment processes make it so teams can’t hide behind delays and release bottlenecks.
  2. Consolidate debt – debt can span across multiple systems and can build up on badly designed and developed code bases – short term fixes perpetuate themselves. If there is bad code to begin with there is not incentive to improve processes in the future. Identifying the biggest problems and balancing new application development and services with fixing legacy issues can help to focus on long term benefits rather than short term fixes.
  3. Seek guidance and counselling – using code and peer level reviews, mentorship and management guidance can help. Often time IT dismisses operational considerations until debt is out of control – a DevOps approach helps by involving IT operations with development to address debt problems.
  4. Avoid ‘spend more’ initiatives – often incentives tied to function points and number of stories delivered or even lines of code written are used by development. This may guarantee a large amount of code but its usability is often not. Incentives do not necessarily promote optimal standards.
  5. Think broadly about debt position – it can be easy to blame development for mounting debt but operations is just as guilty. An example would be a failure to document infrastructural services can lead to longer problem diagnosis times. DevOps collaboration could help by involving the development team in ongoing debt reduction programs.

Technical debt can be deadly, sucking up resources and time that could be spent on innovation, using a DevOps approach could help organizations keep track of their debt and reduce it. Read the full post here: http://www.informationweek.com/strategic-cio/how-devops-can-cut-innovation-crushing-technical-debt/a/d-id/1318677

]]>
http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/feed/ 0
Microservices Architecture & Reducing Technical Debt http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/#comments Fri, 13 Feb 2015 09:14:24 +0000 http://www.ontechnicaldebt.com/?p=3356 read more]]> Paying off technical debt, according to this post, can be made easier with microservices architecture. When building a code base, eventually, trade-offs between quality and delivering on time will arise. The benefit of trade-offs in software is that the option to later go back and fix these shortcuts is available. Quick and dirty shortcuts and expedient design decisions build up over time and create technical debt, which needs to be paid pack before it reaches unmanageable levels. This entails refactoring bad code and reviewing questionable design decisions before defaulting on the debt created. Once the debt has been defaulted on, things start breaking all over the code base and makes working almost impossible.

Microservices architecture could offer an easier way to pay back technical debt in a software environment where delivery speed is increasingly more important. By breaking down app functionality into API-accessible microservices, each service with its own purpose, paying technical debt can be done incrementally service by service.

There are a few reasons why microservice architecture may prove to be a little more difficult to enact than it seems; first is the difficulty in testing microservices-based-apps and second is that it is not always clear what a microservice necessarily entails. Lack of testing is often a source of technical debt because when pressed to meet stringent deadlines the testing cycle is often cut short – therefore, if testing becomes more complex, the more likely skipping them becomes. Also, in creating microservices architecture it is possible mess up and end up creating bad architecture, and bad architecture is the hardest technical debt to pay off.

Although there are complications to using microservices architecture it is likely to continue its growth in popularity. The ease in paying technical debt with this architecture is not the only reason for this, but also because it allows tapping into an existing service rather than coding from scratch. It also gives business the ability to create applications that are adaptable to change over time. However, microservices do not magically resolve problems of technical debt instantaneously; recording where and how much debt exists in the code base is necessary for any organization to keep its debt in check.

The environment in which development is occurring has just as much to do with successfully managing debt as what architecture or techniques are used to address it. If impossible deadlines are the norm, than technical debt often is passed down the line and results in high developer turn over within an organization; there is not much to be done in such a case and debt default is likely.

To read the full post go to: http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html 

]]>
http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/feed/ 0
Is Technical Debt breaking the Software Development bank balance? http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/ http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/#comments Mon, 02 Feb 2015 09:00:08 +0000 http://www.ontechnicaldebt.com/?p=3349 read more]]> Is technical debt still a valid metaphor in the present global software development world? The answer is yes, and this post goes on to present the benefits of such a metaphor while explaining just what technical debt is exactly. There is a growing concern on tech debt not simply because of the costs associated with it but also because mounting technical debt can delay delivery and turn into lost customer satisfaction. The impact of technical debt is often contrary to the many proposed benefits of agile development. Technical debt is the left over work from quick and dirty software – this debt is paid back from the extra efforts later on by developers to clean-up the messy code. When technical debt accumulates over time it can begin to affect the actually financial debt of an organization – either through extra man hours needed, profits lost due to late delivery, or poor user satisfaction.

Developing software quickly is becoming a growing challenge in the industry and maintaining the legacy applications within software is becoming increasingly tedious due to software complexity. This can lead to the popular use of technical debt and brittle code that is difficult to maintain and is often dreaded by developers for fear that changing one thing will have repercussions in other parts of the code. Inheriting technical debt due to open source is also becoming an issue. Open source has crown rapidly within commercial development projects, so what seems at first like source of innovation can often turn into technical debt in the future.

The metaphor of technical debt should be used to increase dialogue between development and business in order to associate the costs to business that are a direct result of decisions made during the development process. Short term speed and first to market advantage may not be worth the long term delays and costs that come as a result of mounting technical debt. Agile as a development method has been around fro some time now, but what is new is making development tools that support such a method. Making sure that automated testing is built into the process of short iterative development is highly beneficial to scoping out code issues early and avoiding technical debt build up.

To read the full post go to: http://www.computerweekly.com/blogs/cwdn/2011/09/is-technical-debt-breaking-the-software-development-bank-balance.html?asrc=EM_NLN_39160385&uid=12933816&utm_medium=EM&utm_source=NLN&utm_campaign=20150128_Word+of+the+Day%3A+technical+debt_mrouse

]]>
http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/feed/ 0