Popular Post
-
![Agilemania Blog]()
Agilemania – Gold SPCT partner of ...
Jul 26th 2022 - BY Agilemania
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
- Naveen Kumar Singh
- Jul 31st 2016
Many people get confused between technical debts and non-functional requirements. Defects can't be technical debts because technical debts doesn't mean not meeting requirement 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 requirement, product not fit for use or poor performance etc. Many time these confusions are created by agile doctors (agile coaches). Maybe those doctors are not from 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. So 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.
What is technical debts?
Martin Fowler has described very beautifully here. But just to make it easier to understand I am adding some examples that I have faced in past.1st Example
I was working on an insurance product in 2007 and we were developing a portal. Actual product was WINS (AS 400) and we were tasked to create portal using asp.net. Since backend was AS400 so there was another team writing middleware using BizTalk. 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 passes we were running behind schedule. Every time we needed any change, we were contacting 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 so the front-end team started bypassing middleware and started pointing to backend directly in order to reduce time in fixing defects. We were able to fix defects and delivered it on time. We did maintain log for all such changes so the middleware team can fix permanently in 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.2nd Example
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 all has been written.3rd Example
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.Above are not defects but debts. Debts usually get created due to below reason.
- Business pressure – Business care about functionality and not about code quality.
- Parallel development – When a team try to meet deadlines by putting more people.
- Lack of technical skills and knowledge – Not investing enough on learning good practices such as TDD, Refactoring and emergent design etc.
- Lack of documentation – Misconception nowadays due to poor understanding about agile. Where people think agile means no documents or don’t understand the value of living documents.
- Lack of ownership – This is very common when you outsource your development because many time outsourcing company don’t take ownership.
- Poor design skills – Again very common when you engage low-cost engineers with less experience
- Many more. Check here
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.
Find Our Upcoming Trainings
Naveen Kumar Singh
Naveen is a Lean-Agile Coach, Professional Scrum Trainer (PST) and Internationally acclaimed Speaker in many Conferences and Agile events.
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Popular Post
-
![Agilemania Blog]()
Agilemania – Gold SPCT partner of ...
Jul 26th 2022 - BY Agilemania
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
Agilemania is a group of passionate Lean-Agile-DevOps consultants and trainers focused on delivering measurable, sustainable results for our clients.
Connect with us on Social Media
Knowledge Area
Certified Partners
Agilemania Technologies Private Limited © 2024 All rights reserved.
