Naveen Kumar Singh
Naveen is a professional agile coach and has been working independently for a long time in the Asia... Read more
Many people get confused between technical debts and non-functional requirements. Defects can't be technical debts because technical debts don't mean not meeting requirements either functional or technical. Technical debts are related to poor design, poor coding or not having applied appropriate design patterns, etc.
Whereas defects are not meeting requirements, products not fit for use or poor performance, etc. Many times these confusions are created by agile doctors (agile coaches). Maybe those doctors are not from a development background or haven’t written a single line of code in their lifetime. They don’t understand the difference between technical debts and non-functional requirements. Not meeting non-functional requirements means there are defects and those defects can't be considered technical debts.
Below are some examples of both technical debt as well as a non-functional requirement. Please read and let me know if you feel I have mentioned anything incorrectly.
Martin Fowler has described this very beautifully here. But just to make it easier to understand I am adding some examples that I have faced in the past.
I was working on an insurance product in 2007 and we were developing a portal. The actual product was WINS (AS 400) and we were tasked to create a portal using asp.net.
Since the backend was AS400 there was another team writing middleware using BizTalk. The middleware team was developing services and we were supposed to consume those services to write front-end using asp.net.
We started very well but as time passed we were running behind schedule. Every time we needed any change, we contacted the middleware team to make a few changes in the service layer but they were usually over-occupied with too many changes and taking more time to respond.
Since pressure was increasing day by day the front-end team started bypassing middleware and started pointing to the backend directly in order to reduce time in fixing defects. We were able to fix defects and deliver it on time. We did maintain a log for all such changes so the middleware team can fix them permanently in the future.
Unfortunately that future never came but that resulting in increased technical debts because new changes were taking more and more time just to investigate how to fix and where to fix. So basically we did well initially in launching portal on time but subsequent changes took more and more time wherein it was supposed to be taking lesser time as the team was more experienced by then.
Master the art of conquering technical debt and advancing your projects. Unlock key strategies to overcome challenges and propel your initiatives towards success.Start your journey now!
Another case with same product, There were many business rules for generating policy. Those rules were driven through XML and we were using rules engine. There was a method for policy generation which was linked to rules engine and there was a single parameter for that method initially.
As development progress, many team members changed due to various reason. Every new developer has added some more lines of code but they were afraid to make any changes in existing code due to fear of breaking already working functionality. There wasn’t any good documentation either and that created more fear among new developers.
Result was horrible. Same method was having more than 10 overloading methods and more than 100,000 lines of code after 18 months. Nobody tried to refactor code to simplify it. Functionality was perfect but code was a disaster. Every time it was taking 2-3 weeks for new developers just to understand what had been written.
There can be design debts as well and here is an example. We were developing an EMR application in 2009 using WPF, WCF and SQL Server. WPF was pretty new and there wasn’t many experienced developers available but still team decided to learn and develop. Learning took more time but still team were not very confident about MVVM design patterns but business wanted to release it faster.
Team moved forward and started building it without having much understanding about MVVM. Result was good but they wrote code that wasn’t easy to understand and also added lots of extra codes that complicated whole things. We did similar things with another application using Silverlight at the same time.
What is non-functional requirements?
As I said above, non-functional requirements are requirements, not technical debts. If pages taking more time to open and business complains about it then don’t consider it as technical debt. This is a requirement and not meeting requirement means defect. Team has to fix this. Similarly, if system not able to handle load or error messages are not clear means there are defects, not technical debts.
Below are some examples of non-functional requirements. Not meeting these means there are defects and not technical debts. Data security Managing user sessions and securing it Server load management during pick hours and non-pick hours Page loading time Server response time Proper log management Government compliances etc. I hope the above will help you to understand technical debt and what not technical debt is. Still not clear then reach out to me.
Naveen is a professional agile coach and has been working independently for a long time in the Asia Pacific. He works with the software development team and product team to develop awesome products based on empirical processes.WhatsApp Us