On Technical Debt http://www.ontechnicaldebt.com Online Community Wed, 02 Mar 2016 13:00:31 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.7 Technical Debt and Reverse Grind: How to Manage it http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-reverse-grind-how-to-manage-it/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-reverse-grind-how-to-manage-it/#comments Wed, 02 Mar 2016 13:00:31 +0000 http://www.ontechnicaldebt.com/?p=3711 read more]]> It is common practice for a developer to make a quick fix in a software project and to then move onto the next shiny new feature. The development lifecycle is getting increasingly shorter and business goals are beginning to overtake product deadlines rather than the quality of the work being done. 72% of respondents to a DZone survey, said that they often release software before it has adequate testing – this is leading to many projects devolving into mountains of messy code. Two popular devops concepts come into play here: technical debt and reverse grind.

Technical debt, simply put, is the cost of taking shortcuts either through lack of testing, pushing code out to production too soon, or poor documentation. If you let these items go unchecked you can end up in a scenario where you are technically bankrupt. Reverse grind is a concept that first became popular in the gaming scene: it means having to repeat repetitive tasks which need to be done in order to achieve some other goal. Grind is the accumulation of redundant tasks that if they had been done in a scheduled manner over time, wouldn’t be a big deal, but when left to do all at once they become extremely tedious.

So what are technical debt and reverse grind costing your organization? They both harm productivity and ultimately cost you money. For each line of code, according to the 2011 CRASH Report (of which there are more recent editions) technical debt costs $3.61. For java developers it gets more expensive with every line of code carrying $5.42 of technical debt.

To put into more tangible terms:

  • a simple iOS app carries about 10,000 lines of code, at $3.61 of technical debt per line of code this app has $36,100 of technical debt.
  • the Mars curiosity rover has about 5 million lines of code, at $3.61 of technical debt per line of code the rover has $18,050,000 of technical debt.

Technical debt can clearly start to add up in cost depending on the scale of a project. So how do you reduce technical debt and reverse grind’s impact?

Following a continuous delivery pipeline allows you to be able to track code commits as they go through each stage of testing and staging before deployment – if any issue shows up in the pipeline you can either automatically or manually halt the process. A team can also roll back to the last working release while an issue is being worked out. Visibility for the whole team is what is beneficial about the continuos delivery pipeline. Proper documentation is also important to implement. It is supposed to be common practice but often falls to the wayside. Proper documentation equals to shared product knowledge and increased productivity – it allows for any one working on a section of code to be able to understand what is being done.

However, the most nebulous step that needs to be taken in order to combat technical debt and reverse grind is company culture. If deadlines set by non-technical stakeholders are causing tech debt to accumulate. or if only one developer has the adequate knowledge of a product to resolve issues there is a problem. First you need to be able to communicate with stakeholders about how much time needs to be given in order to create a proper product, and if you only have one developer with full product knowledge they are going to burn out and take all their valuable knowledge with them.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-reverse-grind-how-to-manage-it/feed/ 0
The Machine Learning Hype Dampened by Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-machine-learning-hype-dampened-by-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-machine-learning-hype-dampened-by-technical-debt/#comments Mon, 29 Feb 2016 15:28:52 +0000 http://www.ontechnicaldebt.com/?p=3707 read more]]> There has become a recent trend in discussing the benefits of machine learning – however, despite its recent popularity there are few large-scale systems that actually employ it in production. A lot of the talk surrounding machine learning is thus about its potential rather than its actual application. This means that talk about the risks that come with using machine learning are often overlooked.

The actual building of machine learning is not a necessarily complex process. With new tools, frameworks, and platforms constantly developing, machine learning has become a hot buzz word similar to when cloud and big data were used as selling points at any company or start-up a few years ago. Machine learning is the product of both – it is the natural progression in the evolution of analytics and data science.  However, there is a catch – machine learning is susceptible to an issue that while not as catchy as cloud security and privacy, it has to do with building a system seem simple but are plagued with a compounding set of issues. This is technical debt.

The issues that stem from this are not immediately recognizable but threaten the reputation of machine learning as the next phase of basic data analysis. Software frameworks are not assembled from entirely unknown parts, therefore, what makes machine learning difficult to use is not a hardware or software issue but a system-level issue. Often when talking about the issue with machine learning it is summarized as a black-box – that we can’t see what is occurring within – but ultimately the greater issue is technical debt. Along with technical debt come the code and maintenance issues that any large software project has to grabble with.

Developing machine learning is enticing because it is relatively fast and cheap to develop – but the other side of this is that its maintenance is difficult and expensive. These systems have all the problems of traditional code with the addition of a new set of machine learning specific problems. For example, the extent of technical debt in a system can go undetected for quite some time because it rests at the system-level. Technical debt, simply put, means that small issues compound over time and thus become more difficult to manage the more time they are left alone. When this technical debt rests at the system-level, it is difficult to tackle technical debt quickly because often times it is not apparent until it is too late.

Traditional technical debt management (as we often talk about here on the blog) is not enough to deal with the system-level debt incurred with machine learning systems. Data dependencies create dependency debt, feedback loops create analysis debt – these forms of debt have comparable obstacles as data testing, process management, and cultural debt. So what does that mean for machine learning technical debt? It means that awareness from the get-go is a must. So much of machine learning devoted to intelligence, therefore, rerouting work to pay off debt is not a simple task: with all the glue code, pipeline jungles, and experimental codepaths shining a light on possible vulnerabilities is hard.

All systems are ultimately plagued with similar issues; whether it be pipelining, job scheduling, or dealing with multiple versions of code. But the particular problem that machine learning has to grapple with is that there are not a large amount of machine learning systems running in full production (unlike HPC sites), and so there are not solutions readily available for this specific problem set. Machine learning is based on many moving parts and glue code so it is extremely easy to dig yourself deep into debt. As more and more organizations move past classic big data tools and look for new intelligent analysis with machine learning keep an eye out for technical debt.

This like any organization looking to deal with technical debt could mean a shift in culture; prioritizing and rewarding efforts to pay back technical debt is an important step for the long-term success of machine learning.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/the-machine-learning-hype-dampened-by-technical-debt/feed/ 0
Improving Software Quality to Avoid System Failure http://www.ontechnicaldebt.com/uncategorized/improving-software-quality-to-avoid-system-failure/ http://www.ontechnicaldebt.com/uncategorized/improving-software-quality-to-avoid-system-failure/#comments Thu, 25 Feb 2016 10:30:47 +0000 http://www.ontechnicaldebt.com/?p=3699 read more]]> In 2015 there was a major slew of headlines dedicated to software failures at major companies (US Airlines, Wall Street Journal, the New York Stock Exchange, and the Royal Bank of Scotland to name a few) which led to a discussion of best practices for software development. This post talks more specifically about UK banking and software quality, but the principles are applicable across all areas. IT visibility, which is imperative to managing technical debt, has come to the forefront of the software industry.

Many systems used by large organizations have been built upon decades old legacy systems which have become hyper-convoluted. These systems, in order to meet the fast-paced demands of consumers have been adding new features and functionality onto creaky and complex old systems. New services like online banking, contactless payments, and Apple Pay (in the banking industry) are a must for customers who expect convenient products at their disposal. Each of these additions increases the risk of system failure, and as they become more complex being able to discover possible vulnerabilities becomes more difficult. Software assurance, therefore, has revolved around functional and load testing, and manual code reviews.

These approaches, however, do not safeguard against system level structural flaws. We have talked about issues like this before, where burdened legacy systems with technical debt are difficult to modify or test because any change could result in an unwanted breakage. Without being able to test for structural faults, these faults can go undetected for years. You will be persistently working in risky conditions you are unaware of, until the day when a new bit of functionality brings the whole system tumbling down. The traditional methods for measuring software quality (including technical debt) are great for the actual process of software development but not for the maintenance of aging platforms.

Like we have mentioned many times, the first step to dealing with any software quality issues (technical debt) is to review it and quantify it. Without knowing where your vulnerabilities lie and how prevalent they are in your system it is nearly impossible to manage the risk of system outages. Numerical values for software quality and technical debt are imperative for objective decision making; deciding what work needs to be handled now and which can be left for later. Comparing your numbers to industry benchmarks can be extremely helpful in this case. CISQ (Consortium for IT Software Quality) has code quality standards which compare source code against these benchmarks – you can then measure your code against these standards to detect vulnerabilities and assess your technical debt. This sort of comparison should be done for every release until your code quality and technical debt are under control.

Automation is the next key step in the process of handling software risk. This can be done with platforms like CAST AIP which incorporates the industry standards of CISQ into its processes. There are several moves that can be taken to then ensure the maintenance of software quality like: structural testing before deployment in order to avoid having to undergo rewrites and going forward with updates and patches with caution.

Ultimately, as software development and customer expectations advance rapidly it is of tantamount importance to make sure that your practices and quality of code don’t fall behind. Allowing this to happen can lead to heavy build up of technical debt, complexity, scalability, and reliability issues.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/improving-software-quality-to-avoid-system-failure/feed/ 0
How Technical Debt Can Help You Be Innovative http://www.ontechnicaldebt.com/uncategorized/how-technical-debt-can-help-you-be-innovative/ http://www.ontechnicaldebt.com/uncategorized/how-technical-debt-can-help-you-be-innovative/#comments Mon, 22 Feb 2016 13:00:46 +0000 http://www.ontechnicaldebt.com/?p=3694 read more]]> Vision is a term often employed to describe leaders: i.e “they have vision” or “they are visionaries”. But vision itself is a rather arbitrary term that doesn’t necessarily have defined metrics to qualify who has it and who doesn’t. In the software world, technical debt maybe the best way to determine who has vision; it is the baseline to see who cares more about the short-term vs. the future.

The most common version of explaining technical debt is that it is the cost of future features; however, what the metaphor tries to truly explain is the balance of satisfying the short-term at the cost of long-term consequences. Given this, technical debt is not necessarily an entirely bad thing. There are certain levels to tech debt that are beneficial to any organization. The amount of technical debt that is beneficial depends on the stage of companies development. For early stage companies the threshold for acceptable technical debt is 40%, for more mature companies 20% tech debt is the max. Once you cross over these thresholds you are running the risk of releasing a product with issues that negatively impact customers – this where technical debt can be severely detrimental to your organization’s reputation and customer retention rate. If you operate within these boundaries you are being innovative without necessarily being reckless.

Your technical debt should ultimately decrease as your level of experimentation does. This means that as your product/market fit matures and develops your levels of technical debt should begin to shrink. At this point you should be focusing on doing a few things, but doing them well.

If you begin to drift off into the direction of exceeding these technical debt limits, your organization’s long-term goals can come into question. It is common practice that when you need to release a new feature to take certain shortcuts for the sake of making a deadline. Therefore, technical debt is often created in a rush. The issue is that for future releases this technical debt makes it more difficult to maintain productivity levels – before releasing a new feature you have to go and clean up the tech debt that was left over from before.

When you have a single developer working on a project who understands the direct result of the trade-offs that occur when taking on technical debt these issues aren’t such a big deal. But when your organization is trying to scale its developer team then technical debt takes its toll by slowing down the productivity of every single new developers who needs to learn what shortcuts have been taken in the codebase. This wastes resources and slows down longterm growth – so any business leader cannot be considered “visionary” if they are letting technical debt get in the way of their organization’s growth.

You can also infer quite a bit about a company based on their approach to technical debt. If a company is persistently more concerned about delivering features now at the expense of long-term sufficiency than they’re either not going to be around for long, are losing market share to competitors and need to keep pushing out functionality to keep up, or there’s a lack of communication between sales and the product team. If you have a lot of technical debt but you’re not necessarily pushing out any new features it means you have sloppy developers – but although your developers maybe pushing out sloppy code it is usually the result of a company culture that does not motivate them properly or engage with them to correct the problem. If a company can create new products while maintaining their flagship products, they probably have a handle on their technical debt due to effective leadership.

As mentioned at the start of this post there is a threshold of technical debt that is acceptable depending on the stage a company is at. Gaining visibility and metrics on technical debt is therefore necessary in order to not only keep technical debt under control, but to bolster innovation. There are products that do just this (like CAST AIP) and can be a great asset for any organization.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/how-technical-debt-can-help-you-be-innovative/feed/ 0
Technical Debt and Breaking Down “Tribal Speak” http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-breaking-down-tribal-speak/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-breaking-down-tribal-speak/#comments Fri, 05 Feb 2016 13:00:43 +0000 http://www.ontechnicaldebt.com/?p=3688 read more]]> In this great podcast from .Net Rocks! the discussion on how to handle technical debt takes an interesting turn towards the discrepancy in communication between different stakeholders on a software project. Most posts on our blog, as well as most other posts out there on technical debt, access the developer mindset. This means that when we talk about technical debt we are thinking about it from a perspective that does not necessarily help convince those managers that are focused on meeting their performance goals and have a hard time picturing the benefit of allowing a developer team to spend 20% of their time cleaning up old code.

To many managers this paying back of technical debt is a hindrance to meeting company goals because they are not understanding what is behind the term technical debt. What these managers need to understand is that reducing technical debt is a big picture goal. However, much of the weight on communicating this big picture importance of technical debt rests on the shoulders of developers – and as mentioned in this podcast, developers are not widely known for their “command of soft skills” (aka speaking persuasively to business stakeholders). Perhaps then the best way to get across the importance of technical debt reduction would be to approach it from the mindset of a business stakeholder concerned with meeting his/her performance goals?

DevOps can fit nicely into a scenario like this, as technical debt’s ramifications can begin to show themselves on the operations end and therefore make its costs visible to managers. This way you don’t have to persuasive when talking about technical debt, but simply show the numbers. The issue that managers mostly have with paying down technical debt is that they don’t see that it is not just an expense, but that it has a return on investment.

Ultimately, communication is the main inhibitor when trying to manage technical debt. It helps to think about what technical debt really means. Inherently, the assumption is that it is a purely technical term. But technical debt is not something that comes to fruition due to a lack of skill but due to a lack of time. Time is a concept that isn’t specific from team to team and therefore be used to create awareness on the issue of technical debt.

The other issue that comes about when you actually want to back and refactor code and you aren’t even sure of how much debt you have accumulated. If you don’t know how much debt you have how are you supposed to demonstrate the value in paying it back? If you don’t address this black box complexity, debt simply continues to grow and it becomes more difficult to add code or fix small problems. Fixing this decline in velocity becomes paramount and defining the reasons for the decline in velocity is central to fixing the problem. Here is where the technical debt metaphor comes into play.

There may be developers out there who enjoy debugging complex code and finding these developers to join your team maybe the solution. However, these types of developers are few and far between. So the true solution is improving communication on technical debt between domain experts, user interface people, and developers. Improving these dormant lines of communication means developing a shared language between all stakeholders in a project.

This means breaking down “tribal speak” (developer language vs. test language vs. domain language). How do you go about doing this? Working through business cases together by going into details and questions from all perspectives can be effective. Also iterating discussions throughout the lifetime of an application is necessary; you can’t just sit down once and expect everyone to come out of a meeting understanding every aspect of a project perfectly. Therefore, when meeting with all stakeholders a common glossary, to ensure that everyone agrees on what terms really mean, is imperative.

Developers are the most most adept at dealing with the ambiguities that come about from certain terms in a project because they are the ones that most often work between teams and work directly in fixing the glitches that arise in code. Just as in natural, colloquial language, software language has ambiguities.

Ex. “Cut trees down and then cut them up.”

The assumption that arises when talking about technical debt is that you or someone else has done something wrong. But it is again important to communicate that technical debt doesn’t necessarily have anything to do with skill level. So instrumenting and measuring technical debt (you can use tools like CAST AIP) can begin to demonstrate the cost of technical debt and help to trace out the differences between accidental and essential technical debt. Once you can measure technical debt and its cost, you can begin to see where unrealistic deadlines are causing unnecessary technical debt and what baseline of technical debt you are willing to accept in a product.

Just make sure that throughout this whole process communication does not break down and devolve into “tribal speak”.

To listen to the full original podcast, visit here.

 

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-and-breaking-down-tribal-speak/feed/ 0
How Innovation Debt Is Just As Damaging as Technical Debt http://www.ontechnicaldebt.com/uncategorized/how-innovation-debt-is-just-as-damaging-as-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/how-innovation-debt-is-just-as-damaging-as-technical-debt/#comments Mon, 01 Feb 2016 13:00:03 +0000 http://www.ontechnicaldebt.com/?p=3684 read more]]> Often times in the development process large amounts of technical debt result in stalled innovation from a given team. However, what happens when what is stalling innovation is not only poor development practices but insufficient investment in developers themselves? This would be what is called, in this article, innovation debt. This sort of debt is comparable to technical debt in that a lack of attention to maintaining clean code results in long term deficiencies, the same way that a team which is too busy preparing new features for an app can’t learn about changes in languages, frameworks, libraries, or tools.

Over time a poor codebase will become extremely costly for an organization, and the same can be said for a lack of training and free space as it limits a team’s productivity and will make it so a team no longer has the skills to properly maintain in-house legacy systems and applications.

This innovation debt reveals its costs in the following terms:

  • Your best developers will start to leave
  • It will then be more difficult to fill these vacancies
  • Productivity will begin to fall
  • And your software will become brittle

So how do you avoid building up innovation debt?

Ultimately, the components that are necessary for continued training have to be incorporated into your corporate structure. This is just how organizations should be dealing with technical debt: baking in good coding practices into their business processes. For dealing with innovation debt these continued training practices could manifest themselves as monthly meetings where team members present an interesting issue area they have worked on or as a company directive to send developers to conferences in order to keep up with the latest trends.

Prioritizing knowledge sharing whether from external or internal sources is integral to raising the threshold for collective team knowledge and skill. However, this new focus on experimentation and learning means that an acceptance and expectation for failure also has to be taken into account by the organization. Trying out new methods and technologies comes with inherent risk; therefore, creating an environment where failure is not immediately reprimanded is conducive to innovation. Invaluable learning can take place from what seem like purely failures – your team can begin to form its own framework on what technologies work in a given circumstance, and which do not.

To read the full post innovation debt and how to avoid and manage it, visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/how-innovation-debt-is-just-as-damaging-as-technical-debt/feed/ 0
Maintaining Technical Debt and Team Morale in a Large System http://www.ontechnicaldebt.com/uncategorized/maintaining-technical-debt-and-team-morale-in-a-large-system/ http://www.ontechnicaldebt.com/uncategorized/maintaining-technical-debt-and-team-morale-in-a-large-system/#comments Thu, 28 Jan 2016 13:00:50 +0000 http://www.ontechnicaldebt.com/?p=3678 read more]]> In this post from InfoQ, Thomas Bradford explains his experience on working with a monolith java-based system that had improper test coverage and huge technical debt.

When asked what the biggest issue would be when maintaining a large java system, Bradford responded that the prevalence of legacy code riddled with quality issues. This leads to a situation where developers can’t modify the system or fix bugs because they might end up simply introducing more due to code complexity and previous development practices (heaps of technical debt).

The technical debt that was present in the legacy code that Bradford was working with was due to the system having been built quickly and as a monolith. This resulted in little to no test coverage (depending on the section of code you were looking at) and the monolithic style of the system created a mess of code with duplicated sections and long methods. A scenario like this makes maintenance extremely difficult and demonstrates an environment where little to no effort had been spent getting the system under control.

One of the biggest motivators to change the way thing were being done and to improve the system came when Bradford heard from various technical leads that often times a product would be rewritten twice, each time with little variance in the result. There was clearly a problem in the code base that kept developers from delivering features efficiently. Bradford said that asides from changing the strategy of working on the java system there also had to be a philosophical change in how developers worked.

Strategically it is impossible to simply ignore technical debt that has built up in a codebase, and that is true in any system. If you allow the technical debt build up to continue you will eventually reach a point where developers won’t be able to release any new functionality due to bricked-in code or because developers are so frustrated by the sluggish pace in which they are able to work. Philosophically, Bradford suggested that developers distance themselves from the practices they had become used to over the years (which had caused the slew of technical debt issues in the system) and begin to approach problems with a new mindset.

In order to deal with the insufficient test coverage that had become problematic in the monolithic java system first there had to be an internal effort to get the system under control. Following that effort, unit test coverage was built up but only in the areas that were particularly difficult to work on. But ultimately expanding test coverage in this manner is not the be-all and end-all of problems in a tech debt burdened system. Radical architectural refactoring that takes the monolithic system and start decoupling it has to occur.

Another important aspect of Bradford’s interview has to do with sinking team morale that often is the result of a system burdened by technical debt and quick-and-dirty practices. Bradford mentions how developers were afraid to change anything in the code base because in the monolithic system one change could have major unforeseen consequences in another part of the system. By enacting the changes mentioned above and giving developers more autonomy and trust in managing the system they work with daily, morale can only get better.

The idea that work can left until a later moment is a dangerous one, because more often than not it simply goes undone. This is what leads to incurring technical debt. If you find yourself in a situation similar to the one Bradford outlines in the interview, you will have to decide whether a short-term tightening in functionality output is worth avoiding the long-term failure of your organization. The answer to this should be clear: yes it is.

Professional developers have to responsible for the software quality they are building. This means not giving into external pressures to consistently compromising quality because ultimately these compromises will affect everyone in the organization negatively. Its the developers job to make the case for software quality above anything else.

To read the full interview visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/maintaining-technical-debt-and-team-morale-in-a-large-system/feed/ 0
When You Should Start Paying Off Your Technical Debt http://www.ontechnicaldebt.com/uncategorized/when-you-should-start-paying-off-your-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/when-you-should-start-paying-off-your-technical-debt/#comments Mon, 25 Jan 2016 13:08:30 +0000 http://www.ontechnicaldebt.com/?p=3676 read more]]> Much of what comes with being an entrepreneurial leader is knowing when to accept certain tradeoffs. When you have a whole organization under your control it is impossible to constantly uphold a perfect balance; the result is often times compromises and temporary fixes. These compromises and short-term solutions are what is called technical debt. While technical debt is not an inherently negative concept, if left unchecked it become an additional risk in any organization.

At any software company technical debt invariably becomes an important topic of conversation. The focus of these conversations should be on when to let technical debt persist and when to start paying it off. In order to do this though, you need to understand what technical debt entails.

Technical debt is the result of fulfilling an immediate need (with a compromise on the quality of your code) that comes with some serious long-term consequences. And like credit card debt, technical debt has high interest rates that compound over time – making it more difficult to pay off the longer you let it remain in your code.

The CEO of BodeTree discusses how at the inception of any company, in order to find the adequate market fit for their product there is a inherent process of experimentation, adjustment, and iterations of code that lends itself to the creation of technical debt. But when should this technical debt be accepted, and when should you start to plan on paying it back?

If you are looking at a company in its early stages of development then there is likely to be quit a bit of accrued technical debt – this is just part of doing business. So you should be willing to accept technical debt in the following three situations.

  1. When you are dealing with your first big customer: quick iterative development and adjustments lend itself well to this scenario when you are looking to refine the product quickly to customer feedback. Therefore, technical debt becomes the means to an end.
  2. When you are building a minimum viable product due to a lack in secure funding: development work is costly so building quick and dirty may be your only option in order to get the product out on the market.
  3. When you are testing new features in an established product: sometimes a new feature may not even be the right fit for your product or market, so it makes sense to cut corners in development in order to see if the feature is even worth your while.

These are the times when you should let technical debt be; but when should technical debt be seen as an untenable part of your code base?

The time to pay it back would be when it begins to show itself by affecting the performance of your product and the efficiency of the team.

What are the signs of reaching such a point?

You will know that you’ve reached this point when making changes to your product becomes an arduous task to the amount of features that are interconnected. Your code will become brittle and any change could have some serious ramifications in other areas of your code that could result in breakages and software outages.

For BodeTree the signal was clear when a sudden influx of customers revealed what features were not being used and which features weren’t working. The BodeTree team was able to identify what could be cut out and therefore focus on the quality and performance of the code in their system – in the areas that mattered most. A strategy like this saves capital because it allows you to surgically correct the areas where technical debt is the most costly and prioritize your development work accordingly.

The key, as mentioned at the start of this post, is knowing what the right balance is of acceptable and not acceptable technical debt is in your organization.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/when-you-should-start-paying-off-your-technical-debt/feed/ 0
The Risks of Measuring Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-risks-of-measuring-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-risks-of-measuring-technical-debt/#comments Thu, 21 Jan 2016 13:15:37 +0000 http://www.ontechnicaldebt.com/?p=3669 read more]]> It has become a recent practice in organizations to measure technical debt in their software – but how often do you think about why you are measuring technical debt? What will you and your team do once you have information on how much technical debt you have in your software? What risks have you uncovered in the process? Simply because you have the ability to measure technical debt, doesn’t mean you necessarily should.

Measuring technical debt can be extremely valuable but only in the right context. Your organization first needs to have a working definition of what it means for a software component to be complete; in other words, your organization needs to have a measurable definition of “done”. What teams need to keep in mind is that the gap revealed by measuring technical debt (the gap between the work being put to release and what your working definition of ‘done’ is) has far reaching consequences.

The scenario drawn out in this post presents an organization that went through the process of measuring technical debt. However, their software at one point fails causing physical and financial damages to the organization. Here is where the measurement of technical debt can become an issue, especially if your processes are not well equipped to deal with such a failure.

After this failure let’s say you are being questioned by jury on the software failure that occurred and you mention that technical debt was present in the version of the software that was released and then failed; it could then be argued that you deliberately released a product that was flawed and faulty. Even if the technical debt that was present came from poor practices unrelated to functionality (like poorly documented code) these nuances are likely to be lost in a case on business’s liability for the failure.

As software functions today, it is easy to consistently update it thus creating an environment where it is common for organizations to release imperfect or incomplete software. Therefore, if your development team is deliberately measuring and documenting code you could be building a case up against yourself in case of technical failure.

However:

If you have a well moderated risk management policy in place and processes that ease the identification and measurement of technical debt, as well as contingency plans to deal with the risk of building software with technical debt, you are in a better place than without.

Another downside of measuring technical debt is that it impedes innovation. If technical debt measures are demonstrated as persistently increasing it could then be used as another excuse by developers for not delivering features by their deadline. Ultimately, if a business does not consider work that is left undone as a pressing business concern than it should not be labeled technical debt. Instead it should simply be stored in the backlog, along with documented efforts through robust testing, and automation.

So what then is the difference between measuring technical debt and recording defects or publishing known issues? The word debt inherently carries negative connotations; it sounds deliberate and risky (technical debt by definition is both of these things but if you are aware of the technical nuances of inducing technical debt than you know that this is not necessarily a bad thing).

When business and development teams are in synch with their understanding of ensuring that software is meeting predefined standards of software quality that is the time that technical debt measurement is best utilized. If you plan to release software with quantified technical debt present it is necessary that all aspects of business are aware of the risks present of putting speed before quality.

Ensuring that your organization has a set of best practices and follows them closely is imperative to using and managing technical debt to the benefit of your product.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/uncategorized/the-risks-of-measuring-technical-debt/feed/ 0
Technical Debt & Risk: One and the Same http://www.ontechnicaldebt.com/blog/technical-debt-risk-one-and-the-same/ http://www.ontechnicaldebt.com/blog/technical-debt-risk-one-and-the-same/#comments Wed, 06 Jan 2016 13:00:00 +0000 http://www.ontechnicaldebt.com/?p=3666 read more]]> Technical debt is a very important concept to developers that is often lost on the management end. Developers use the concept to describe the consequences of a pressure to meet deadlines; to release features on time developers will write quick and dirty code, compromise on standards, and leave code quality out to dry. Technical debt is the choice between making sustainable software and making short-term decisions that are detrimental to code in the long run.

For management, debt wouldn’t be the term they’d use to describe the concept – but they would rather see it as the risk of increasing costs or missed deployment schedules due to the current development process. Any code written has inherent risk associated with it. Therefore, technical debt is not seen as something ineffectual, but as, sometimes, a necessary risk. To be able to decide whether the risk is acceptable or not technical debt has to be quantified.

There are several ways to measure the presence of technical debt in a code base:

  • Estimate Accuracy: without technical debt the estimations of time needed to develop a certain feature would become more accurate overtime. As developer knowledge in a certain area increases (knowledge on tools and frameworks, team performance, etc) estimations by developers would become more accurate. If this is not happening (and estimations become less accurate and more difficult to pinpoint) it is likely that the system is plagued with technical debt. The decreasing accuracy of estimates can be measured and, therefore, be used to measure technical debt.
  • Time to First Feature: the time for adaption by new hires is a useful metric for technical debt. This encompasses the comprehensibility of the code and the developer’s own ability to understand the code. Both of these components are important, but if it has become typical that new hires need more time to bring components into production “it is likely that that the learning curve has become too flat”. Technical debt is often the cause of this.
  • Internal Metrics Failures: developers and devops often use tools and metrics to see if code is meeting certain standards. It is likely that your development team already has an internal tool in place to track that status of software; it can be the case that this tool indicates poor behaviour most of the time, and that can be normal. But also keep in mind, that if you have a component that has been marked for 30 days as performing below satisfactory, there’s probably technical debt present. The duration of failure to meet standards is a key indicator technical debt.

So once you’ve measured the presence of technical debt in your system, how do you manage it?

Technical debt is often seen as solely a negative thing, but just as we mentioned that risk is inherent to code – technical debt is also inherent to a system. Many teams immediately fight against technical debt, even before it has actually shown itself to be present. Other teams entirely ignore technical debt, mounting pressure on their developers and digging themselves into a deeper debt.

Ultimately, it is necessary to know how much debt you are incurring. This means either documenting debt in the moment, or when it starts showing itself in the system. The latter option is perhaps the better one, as it automatically helps prioritize those debts that need to be addressed first.

Once you know where and how much debt you have, repaying it from time to time is important. It is best to repay it sooner rather than later, because the longer they are in a system the harder it is to identify. Refactoring is the best way to go about this. This means that there will probably always be certain levels of technical debt present in your system, which means certain levels of risk, so preparing for possible failures with a contingency plan is also a good idea.

Dealing with technical debt is dealing with risk. In a business you can’t be risk-averse, but deal with it smartly. If you deal with technical debt in the ways mentioned above, you system should be safe from any from any major problems and enable business growth.

To read the full post visit here.

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-risk-one-and-the-same/feed/ 0