Stephanie Watkins
Stephanie Watkins -
Strategies to fix technical debt is a topic that’s not going unnoticed this year.
Technical Debt for Continuous Innovation: Strategies to Avoid
Technical debt is a huge problem for many organizations today and if it’s not being addressed, it’s growing. Growing technical debt takes away from funds for innovation, and instead uses it toward maintenance.
Technical Debt: 3 Biggest Organizational Mistakes
Technical Debt standards have been debated for many years.  And now CISQ (Consortium for IT Software Quality) has released standard that not only measures by automates technical debt calculation in complex software systems.
Technical Debt: CISQ Releases New Standard to Define and Measure Technical Debt
Technical debt and DevOps are two topics on every organizations mind.  Yet, no one tackles the topic better than this article
Technical Debt & DevOps: 5 factors fueling automation in IT
Technical debt is at the top of developers pain points, and according to some this is due to a flurry of new development styles that have come into vogue. The software industry's focus on rapid application development, as necessary for business agility, has furthered the problem of technical debt. Fast implementation of containers and microservices lead to DevOps teams facing serious tech debt management issues.
The Pain Point of Technical Debt
A distinction that we always try to make in our posts is that there is both good and bad technical debt. This is similar to how there are ways in which financial debt can be used to strategically help a company
Technical Debt The Right Way
Last week we published a post about the Consortium for IT Software Quality's (CISQ) initiative to come up with a standard technical debt measure through a survey distributed to developers.
Contribute to CISQ's Technical Debt Remediation Survey
As we quickly head into the new year - the Consortium for IT Software Quality (CISQ) is working to develop a new measure for technical debt.
CISQ to Develop Technical Debt Standard Measure
Cars are no longer simple pieces of machinery, but have evolved into highly integrated pieces of technology - with software embedded into all their critical systems.
Technical Debt & Safety Critical Systems in Automobiles: The Road Ahead
As a metaphor, technical debt relies on the fact that those who hear it understand the financial concepts that the metaphor relies on.
How To Reframe Technical Debt: A Painter and A Paint Bucket
A while ago we published a post on IDC predictions that the bi-modal IT approach is a recipe for disaster. There are different opinions on what works in software development: those who support the siloed approach of bi-modal IT, those who urge against this division between predicability and innovation, and others who say fast development is the only way. This debate is only just beginning so it's worth while expanding on the arguments surrounding it.
Innovating While Maintaining Stability: A Lesson From Technical Debt
There are always trade offs to be made when you're dealing with keeping your application portfolio up-to-date. You always have several options, whether it be modernization through migration/refactoring or by a sort of "transformative leap".
How to Mitigate the Technology Gap and Manage Technical Debt
There's bad news ahead for organizations that focused on a bimodal IT approach. According to research firm IDC by 2019 80% of those firms will have accrued crippling amounts of technical debt leading to increased complexity, cost, and a hit to their reputation.
Is the Bimodal IT Approach an Invitation to Failure?
Technical debt has not only become a popular industry term, but it has proven itself to be an important concept.
The Human Side of Technical Debt
Technical debt can arise from many places and today we will focus on poorly used and created feature flags.
Feature Flags: Good, Bad, or Both?
Technical debt starts off from building fast and making a slew of decisions based on short-term needs that are detrimental to your products long-term stability and maintainability.
Technical Debt: What is it and What to do When You Have it?
Here, at On Technical Debt, we often discuss the difficulties of communicating technical debt to business stakeholders, the consequences that arise from it, and the ways to about paying it back - but in this post we are going  to focus on why it is there to begin with.
The "Why" of Technical Debt
This summer Southwest Airlines underwent various technical failures that led to the cancellation of 2,300 flights over the span of four days. This cost the airline approximately $54 million.
How to Avoid Technical Failure by Recognizing the Consequences of Technical Debt
Remodeling software should be done in the same mindset under which we remodel a house: to make it last longer and run better. Companies should be invested in mending their code to be able to get more productivity out of it.
Stop Paying Back Technical Debt, Accumulate Technical Wealth
The project triangle is a well known model to many, even the most junior of software developers know it.
Is The Technical Debt Metaphor Actually Helpful?
This is a great post from the Software Engineering Institute on early software defect detections with technical debt.
Detecting Software Vulnerabilities with Technical Debt
When it come to the struggles of undergoing digital transformation, many organizations are going about their digital transformation though a bimodal approach, and according to this post, this is unsustainable.
Integrating Innovation and Legacy Systems: Reducing Technical Debt in Digital Transformation
A new generation of IT professionals has been faced with the challenge of delivering agile and digitally enabled products, all the while maintaining legacy systems that many systems still rely on.
Balancing Legacy Systems and the need to Modernize
In this post the CEO of ActiveState discusses how at the organization they have dealt with the discovery that they had high levels of technical debt.
Technical Debt: Much More Than Just Code
What can CFOs do to lead their company's away from the mountains of technical debt?
A CFOs Guide To Leaving Technical Debt Behind
When you look at a company like Amazon, a company that is a leader in providing a smooth digital experience to its customers that leads to high satisfaction, its important to know infrastructure and operations framework that has been put  in place in order to make this feasible. DevOps plays an integral part in allowing Amazon to maintain its status as an industry leader.
Bringing Technical Debt and DevOps out of the IT Department
In the evolution of technology, one of the major components of its trajectory is that it has become integrated in every possible product.
Software and Code Quality in Automobile Safety-Critical Applications
Looking at the software industry as it stands, it would accurate to assume that most working in it don't know what technical excellence is
How to build code with Technical Excellence
This great articlefrom Forbes starts off with a good physical and personal analogy for technical debt:
The Silent Killer: Technical Debt
Looking at technical debt in a negative light, as something that stands in the way of new features when it grows, equates it to a credit card.
The Differences between Technical Debt and Financial Debt
One of the great things about the technical debt metaphor is that it expanded the conversation on software entropy and complexity to include the business that software is used by and maintained for.
Strategizing Your Technical Debt: The Good, The Bad, and The Necessary
Here's a great post that discusses how Monsanto is not only managing their technical debt but turning it into an asset.
How Monsanto changed its management of Technical Debt
Technical debt has come around as being the keyword of the moment in the industry.
Technical Debt: Not Just a Technical Problem
Applications and architecture are usually the primary source of technical debt in an IT organization.
Measuring Technical Debt to Increase Quality and Performance
In this post, there is a distinct warning being made to banks in the UK: another banking outage, similar to RBS major failure in 2012, is on its way.
UK Banking at risk of IT Failure and Technical Debt
In simple terms, technical debt is the work that you've been putting off that is needed in order to complete a job.
Get a Grip on your Technical Debt
Mergers and acquisitions can always result in some sort of unplanned issue emerging – whether it be about competition or integrating two disparate IT or HR systems.
On Technical Debt and Mergers and Acquisitions
One of the greatest issues of dealing with technical debt is the brittle code that comes along with it.
How to Avoid the Brittle Code of Technical Debt
A CFO's job is to form a company's investment strategy, and one critical area of investment in any organization is technology.
A CFO's Guide to Technical Debt
Most technical professionals can agree on at least one thing: that things would've been done better and problems would've been solved quicker if they had more time to work on them and if they knew the how negatively the impact of not dealing with these issues would effect software quality.
How To Deal with Technical Debt in Different Environments
When working on a legacy codebase, you might start to wonder how anyone could have ever let it get to be such a mess.
How To Rescue Legacy Code Through Refactoring
Ward Cunningham, when coining the term technical debt, warned of incremental debt that allows code to run effectively but imperfectly.
The Path from Technical Debt to Bad Code
This post presents an interesting and effective analogy to for those of us that struggle with handling technical debt: spilled juice.
How Spilled Juice is just like Technical Debt
A relationship that is often overlooked in software development and maintenance is the one between incidents and technical debt.
The Relationship Between Incident Management and Technical Debt
This post presents an interesting mindset from which to build software: treating infrastructure as code so that the systems and devices which are used in software are treated as software themselves.
Infrastructure as Code and Avoiding Technical Debt
Arlene Minkiewicz, Chief Scientist at Price Systems, recently  presented on the issues relating to technical debt and software maintenance.
At the Intersection of Technical Debt and Software Maintenance Costs
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.
Technical Debt and Reverse Grind: How to Manage it
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.
The Machine Learning Hype Dampened by Technical Debt
In 2015 there was a major slew of headlines dedicated to software failures at major companie which led to a discussion of best practices for software development.
Improving Software Quality to Avoid System Failure
Vision is a term often employed to describe leaders: i.e "they have vision" or "they are visionaries".
How Technical Debt Can Help You Be Innovative
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.
Technical Debt and Breaking Down "Tribal Speak"
Often times in the development process large amounts of technical debt result in stalled innovation from a given team.
How Innovation Debt Is Just As Damaging as Technical Debt
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.
Maintaining Technical Debt and Team Morale in a Large System
Much of what comes with being an entrepreneurial leader is knowing when to accept certain tradeoffs.
When You Should Start Paying Off Your Technical Debt
It has become a recent practice in organizations to measure technical debt in their software.
The Risks of Measuring Technical Debt
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.
Technical Debt and Risk: One and the Same
It's estimated that the federal government spends about $80 billion a year on IT.
Technical Debt & Software Quality Tools
There is always a battle between the amount of time you have to get things done and the amount of work you have to do to get those things done. There is usually less time than what you need to complete all that work. This time vs. work dynamic is what creates technical debt. Hitting a release deadline is often valued over writing clean code, which leads to technical debt build up. This means the next release you are working on is going to take longer, leading you to take on more debt. A cycle like this is dangerous because it leads to poorly constructed code and can even result in system failures.
Defining Technical Debt: What It Is and What It Is Not
In the development cycle there are many places where technical debt can rear its head and cause problems down the line for the product you’re developing. In order to tackle the problem of technical debt first teams need to know what it’s comprised of, how to identify it, and, then, how to address it’s presence in a system.
The Symptoms and Causes of Technical Debt
Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.
The Causes Of Technical Debt Do Not Exist In A Vacuum
Ward Cunningham introduced the technical debt metaphor as a method to highlight the potential for higher costs in product development from postponing some work on software in order to release other parts faster. The comparison between financial debt and the term technical debt was meant to demonstrate the eventual need to complete postponed work and repay the principal of delaying it. Technical debt also alludes to the possibility that interest costs, associated to postponed work, can become so high that they impede any other important work from being done on a project. For these reasons, technical debt is a useful concept – as it clearly communicates the danger of postponing work. However, metaphors often conflate two comparable situations, to two identical treatments of similar situations. This can be avoided in the financial debt/technical debt coupling, by using the financial metaphor to identify the economic forces behind technical debt.
The Economics of Technical Debt
Corporate technology debt (which we will refer to as technical debt) is usually the result of not considering the future effort needed after shortcuts misfire. Recently, CFOs have been taking on the responsibility of IT function, with some IT departments reporting directly to the CFO or relying on them for spending approval. Therefore, awareness of technical debt is necessary for these CFOs. Finance executives, however, will have a different perspective on technical debt than those in IT. For them, technical debt is threatening because it can results in dollars worth of lost opportunities.
A Scorecard for Technical Debt
Technical debt is defined, in this post, as any code that impedes agility as a project matures. This is an important definition to keep in mind as the following attitude towards technical debt is discussed.
Is The Impact Of Technical Debt The Same Everywhere?
This post is based on an interesting paper about managing technical debt at Google.
Managing Technical Debt At Google
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: A Framework for Product Managers
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.
How To Calculate Technical Debt: A Top-Down Approach
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 & Reducing Technical Debt
It is becoming more and more obvious that the software risks and complexity that face today's legacy systems is a growing problem for many IT organizations.
Executive Dinner Series: Managing Software Risk within the Insurance Industry
This is a post that discusses an alternative to the metaphor of technical debt for ‘bad code’. The problem with technical debt as a metaphor is that for managers debt can be a good thing – it can required for financial needs or encouraged by tax breaks in certain financial situations. However, the debt that is often spoken about in codebases does not fully capture the risk that comes along with writing short cuts.
Bad code isn’t Technical Debt, it’s an unhedged Call Option
In this presentation by Kimber Lockhart, as part of the Hack Summit (the virtual conference for programers), she discusses what to do once you’ve inherited bad code. She speaks less about the source of bad code (low budget, high pressure to meet deadlines, company’s decision to hire poor developers) and more on the steps to fix and prevent this code. She does mention that not all bad code is because of technical debt, since for her tech debt comes from a conscious decision to write poor code, but this presentation does address how to get rid of it.
Inheriting Bad Code: How to Fix and Prevent it
Accidental complexity can be referred to as technical debt or sometimes spoken about as incidental complexity – ultimately there is a difference between conscious and unconscious sources of poor code. If it is deliberately decided to deliver suboptimal products, there is a perceived hurry to ship to market. If there is a strong enough incentive to pay the cost of rushing a product, the scenario incurs technical debt because there was a conscious decision to incur that debt. However, this post points out that often when speaking of technical debt, the poor code is not a result of expedited release but because of poor skill or lack of understanding – all in all this code is not tech debt but is sloppy code.
Why is Programming so Hard? – Incidental and Accidental Complexity
Moral hazard is a situation when a party is more likely to take a risk because they are not the ones bearing the possible costs of that risk. This post concludes that one of the sources that can contribute to technical debt is moral hazard – which comes from the person coding being motivated to get the code done quickly and not being cautious of cutting corners because of their lack of commitment to the possible costs.
Technical Debt, Technical Liability, and Moral Hazard
Securing open source - Lev Lesokhin spoke with CSO Online about how large IT organizations can secure their business critical applications from known vulnerabilities and shoddy software quality. Be sure to check...
Software Quality: The Problem with Ignoring the Open Source Quality
This article gives us an in depth look at another type of IT debt: architectural debt. It starts off with the jarring statistic that 72% of IT budgets are usually spent “keeping the lights on” or in other words day-to-day maintenance. The only way to reduce this proportion of the budget dedicated to maintenance is to address its cause.
Architectural Debt and Moving to Software Defined Architectures
With the cost of U.S. data breaches increasing nine percent from last year, and the news of Target CEO Gregg Steinhafel announcing his resignation amidst the fallout of their massive credit card breach, every IT organization has software risk management top of mind in 2014.
Launch Party Wrap-Up: Software Risk Management Goes to Broadway
Anyone whose professional life has intersected with the technical debt metaphor knows its power: the simple proposition that such a thing exists opens up a new channel of communication among groups (IT and application developers, designers, biz dev) that famously have trouble communicating about technical decisions. Not everyone understands test cases, aging platforms, crufty code bases, or security loopholes, but everyone understands debt (needless to say, most everyone has personal debt, and a sizable proportion of the news media conversation concerns debts, mortgages, and deficits).
Can Technical Debt Be Quantified? The Limits And Promise Of The Metaphor
Steve Garnett from Ripple Rock (an IT consulting company that assists customers in improving their software development capabilities) is one of many who has experienced Technical Debt on a project he worked on in the past. His new blog post captures a common problem: you know the Technical Debt is there, you know that it’s going to be difficult to fix… so how do you convince management that you need the time and resources to deal with it?
Prioritizing Your Technical Debt
This interview will focus on the ground-level steps that should be taken in order to help IT teams deal with their Technical Debt in a pragmatic and efficient way, while working in a fast-paced Agile environment.
Pragmatic Ways for Your IT Team to Deal with Technical Debt
This debate will focus on addressing the viewpoints expressed by the founder of the term “Technical Debt,” Ward Cunningham, and those of Capers Jones, which take on a much wider economic approach to the topic.
Technical Debt Debate, with Ward Cunningham & Capers Jones
When operational requirements are ignored, using agile can easily bring on technical debt. A recent blog post on Codovation from Bastian Buch describes that even though it might be impossible to avoid technical debt altogether, there are 5 effective steps to help reduce and control it
5 Steps to Reduce Technical Debt When Using Agile
elow is an updated set of slides from a webinar presented by IEEE Software and Boeing on how to identify and manage technical debt. The slides outline how business and product quality goals should affect the choice of approaches (and combinations of approaches) for managing technical debt. They also discuss a set of automated approaches based on static code analysis that are likely to spot problems in source code that have real impact on productivity and defect proneness.
Identifying and Measuring Technical Debt – IEEE Software & Boeing
The topic of technical debt or the down-stream costs of careless development is one of the fastest-growing software measurements. However, as most widely calculated technical debt is alarmingly incomplete. Pre-release quality costs are usually omitted from technical debt calculations. Even worse, the very high costs of projects that are cancelled and never delivered have zero technical debt.
The Errors and Hazards of Technical Debt
How do you explain Software Debt to a non-software developer? Jason Roberts has put together a Technical Debt Simulator: some simple visualizations of the cost of software debt over time depending on the type of coding practices the developers are implementing, and some tables that give an example of this cost in “days of extra work”. Let’s say we develop low technical quality software in a large and highly complex system, with the technical debt interest rate at 21%, we would have 91 months of additional cost over the life of the system.
A Technical Debt Simulator
Technical Debt exists in many forms. Perhaps the most common concerns software maintainability. Code that is difficult to maintain is more expensive to maintain, plus the development group can’t respond to the business as quickly. So, we can then conclude that code that is poorly-written or difficult-to-read costs the company money – directly or indirectly.
Part II: Practical Examples of Paying Down Technical Debt
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
Technical Debt vs. ROI: Your Code May Be Elegant…