What Is Technical Debt In Software Development And The Impact To The Business?
Today, I would like to talk about technical debt specifically in software development. This is one of the topics that I'm passionate about. In fact, one of the reasons why I'm interested in Scrum is not only because Scrum emphasizes heavily the people aspect in software development but also because Scrum as taught by Ken Schwaber, one of the co-founders of Scrum, emphasizes heavily technical excellence and professionalism in software development. Interestingly if we look around us, there are more and more organizations using Scrum in our industry and at the same time, I also see many organizations care less about technical debt in the product they develop. A lot of people from the business, a lot of managers think that Scrum is only about delivering products fast. Well, that's a very partial view of Scrum. On the other side of the coin, Scrum is also about limiting our risk. Developing products fast with low quality is risky for the business as it may cause a financial impact. A lot of people have the mindset that a Sprint in Scrum is just a shorter waterfall. With this mindset the scope for Sprint is fixed, sadly often this is done by the Product Owner him or herself. Because the scope is fixed and the Sprint is time-boxed, the development team often becomes super creative in cutting corners to be able to deliver all of the scopes that have been fixed for the Sprint. The developers oftentimes are not putting professionalism in developing the software. Technical debt was a term coined by Ward Cunningham back in 1990. Ward was one of the signatories of the Agile Manifesto. Ward Cunningham is considered influential in the agile movement in the industry. Ward likes to use metaphors to explain technical terms to people who do not have any software development background. According to Ward technical debt is a conscious decision to deliver the software faster by cutting corners knowing there will be negative impacts reaped in the future both financially and also technically because currently there is not enough understanding about the technical aspect of the product and also about the business process.
Technical debt, just like financial debt, will create interest in the future in form of low maintainability of the system which will also impact the business financially. Technical debt is often a chosen path as a short-term solution. Martin Fowler who is another agile manifesto signatories has also written a blog about technical debt. You can go to this link here or click the link in the description below to read Martin Fowler's blog on technical debt. Many people think that technical debt is the same as a defect. Technical debt is not a defect because unlike a defective product a product with technical debt is still functioning, the user can still use the product, there is no showstopper but the internals of the software are quite rotten. For example, this code right here on your screen right now is not defective because it will pass the unit test but it has technical debt because the design of the code is properly designed. On the other hand, this code right here on your screen right now has no technical debt but it's defective because it does not pass the unit test. Poorly designed code is just one form of technical debt. Other forms of technical debt in software development are but not limited to not using appropriate design patterns and code convention, hard-coding configuration in the code, the system architecture is tightly coupled, not using appropriate technology for example using PHP rather than Java or using SQL database rather than NoSQL database, lack of unit test code, lack of automated performance test, the codebase that does not comply with security, etc. There are tools in the market that can provide us with insights into the technical debt in our software. An open-source tool like Sonar can give us insights about the technical debt in our software but I would suggest not rely so much on tools like Sonar because not all technical debt in our software can be gathered by tools like sonar. For example, Sonar would not be able to tell us high-level technical debt such as whether we are using the wrong technology. At the end of the day, only experienced software developers know whether the software has technical debt.
In the context of Scrum, technical debt is related to the Definition of Done because in Scrum the Definition of Done should include all of the activities to develop the software professionally because the software that is developed professionally will result in high-quality products. Interestingly when I observed organizations who claim to be doing Scrum, they do not have a solid Definition of Done, and oftentimes this results in a flaky product and when the organization found out after several Sprints they have a flaky product it's not uncommon for these type of organizations to blame it on Scrum. I have already made a video on the Definition of Done. This is a very important topic that is often ignored by organizations implementing Scrum, I suggest you watch the video if you haven't already watched the video. You can click the link up here to watch the video. There are many scenarios of how technical debt happens. I'm going to share some of the common reasons for how technical debt happens. The most common scenario of how technical debt happens is when the Development Team did it deliberately without the management and the Product Owner knowing because the Development Team have no other options because the scope per Sprint has been fixed and the scope and the timeline for the whole project have been locked by the management and also by the product owner so the development teams deliberately cut corners to be able to deliver all of the fixed scopes within the fixed timeline. This scenario often happens when the organization still has that project mindset.
In this scenario, the development team is considered not transparent about their decision. Some technical debt was done by the development team because they do not know a better way. Usually, this is because of capability and experience issues. The Development Team members do not have the capability and do not have enough experience in developing the software professionally. In this scenario, it is important for the development team to continuously learn and improve their mastery in developing software professionally and be transparent both to the management and also to the Product Owner that in the future when they already have all of the capability and the knowledge, they will refactor the product and pay the technical debt in the product incrementally every Sprint. And when the Development Team is courageous and transparent about their lack of capability to develop the software professionally, the management and the Product Owner should support and appreciate them rather than judge them. Some technical debt was made for strategic reasons. Some technical debt was made deliberately with the agreement by the Development Team and also the Product Owner. In this scenario, the development team and the Product Owner agreed to pay the technical debt in the future. The strategic reason for creating technical debt is because the Product Owner wants to validate the idea first and see whether there is any traction in the market for the idea. Even though in this scenario the technical debt is made for strategic reasons, the challenge is when the idea turns out to be successful and the Product Owner forgot about the agreement with the development team and does not allow the development team to pay the technical debt. Creating technical debt is often the path chosen by the developers because they have no other choice. When developers put in technical debt, for this reason, they put aside professionalism. Creating technical debt is considered unprofessional because it cuts out technical excellence that is supposed to be done when doing the work. In other professions, technical excellence is very important. Imagine if you hire a plumber who does not show any technical excellence, your pipe may leak in a few more months and your water bill may increase and in the worst-case scenario, it may damage your whole house. Or if you go to a dentist who takes a shortcut and uses a cheaper solution he or she may risk damaging your tooth in the long term. Any professional dentist will not just do what the client told them to do just because the client think is cheaper and faster. Just like a technical debt in plumbing and in dentistry, technical debt in software development can also create a time bomb in the product. Just like financial debt that creates interest upon interest, technical debt also creates an impact on the business.
Some of which are: it will be more difficult for the development team to maintain the system and keep it up and running, oftentimes adding new features to the system will take longer than it should, oftentimes finding the source of the defect becomes more difficult, the system is vulnerable from outside attacks, the system becomes harder to scale to serve a large number of users. In financial terms, this could mean Reputation in the market, an unsatisfied customer who might be leaving a product for a competitor's product, slower time to market and defeated by competitors who might move faster than us, and sometimes it can lead to bankruptcy. In today's digital age, the software is in almost every aspect of humans life and low-quality software can literally kill people. The case of the Boeing 737s Max is one of those examples.
In the context of Scrum, the Sprint backlog is not only about delivering features. In the context of Scrum, the development team will also pay technical debt incrementally every Sprint and make it as their Sprint Backlog. Product Owners and management should support rather than cajole and intimidate the development teams who are acting professionally paying the technical debt in the product. So that is all from me today folks. Hopefully, you know what technical debt is, and most importantly you are motivated to pay any technical debt in your product incrementally every Sprint. Thanks for watching today's video folks, if you liked today's video don't forget to smash that like button or go buy me a copy from the link here. Please share today's video if you think others in your company will benefit from knowing the financial impacts of technical debt in the product to the company.