Efforts needed for modification, fault removal or for environmental change.
Risk of unexpected effect of modifications.
Efforts needed for validating the modified software.
Ability of the software to be easily operated by a given user in a given environment.
Response time for given throughput.
Combination of Maturity, Fault tolerance and Recoverability for certain point in time.
Main Factors and Sub Factors of Software Quality
Quality Assurance Method
Combination of Maturity, Fault tolerance and Recoverability
Trade-offs between Software Quality Factors
Inappropriate use of resources can reduce availability. For example, holding a particular resource for a long time without using it may cause resource starvation and an inability to handle additional concurrent user requests.
Lack of documentation may delay management and future upgrades in the software.
Increased memory consumption may result in reduced performance.
Increased database server processing may result in reduced throughput.
Complex applications with many processing permutations are not tested consistently, perhaps because automated or granular testing cannot be performed if the application has a monolithic design. Design systems to be modular to support testing.
If the code base is large or complex, the refactoring of the codes will be difficult.
Lack of tracing ability will leads to difficulty in modifiability.
Sometimes you might have came across the word Over-Engineering. The good programmer do that intentionally to avoid the technical debt.
Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Boxing yourself with bad code.
Technical debt keep on raising when you are boxing with the bad code base. The main reason of technical debt is – we are attempting to solve a particular problem in our software with some shortcuts or some quick fix.
Refactoring is the key.
Boxing with bad code will end up making the code base complex to do further changes or maintenance. Refactoring the code time to time will help to make the code more adaptive.
Quick Fix – No longer works
When we are doing a quick fix to any problem, we should aware that we have to accept technical debt we are making. Doing the similar stuff regularly will end up the code base into a worst place to visit.
At some point your code does not allow you to change anything. And you will break something when you attempt to create something or change something.
The increase in technical debt in the software will make the system more fragile. If you attempt to made any crucial fix which urgently needed, you can’t do that without breaking something. That’s the cost we will be paying as interest to the debt we were creating from the beginning time.
The common mistakes which leads to increase the technical debt
Urging into deadline without creating core components
Delivering MVP (Minimum Viable Product)
Working for Now moment
Bringing unaccomplished POC (Proof of Concept) into production
You started killing your code when you started Hard-Coding.
It might sound crazy, hard-coding will make you to do multiple iteration when you are attempt to change something in the software.
Lets consider, you have a warning message throughout the application as “This request has been submitted successfully”. And you have used it in throughout the application in multiple places.
Suddenly, we need to change all the occurrence of warning message into something else. Lets say – “submitted successfully to server.”
Since it is a simple text, you have hard-coded throughout application. And also you have decided that it is going to straight-forward when it needs a change.
Actually it isn’t. So, what would be approach here. How you will be doing the text change in 100 places in your application?
Find and replace?
Regex to match text and replace?
Or by using some magic refactor tool?
Most of the above best cases would have failed if text is split in two lines or didn’t caught during the search. Earlier, I had used language translate service in my angular app.
The application would support multiple language or variant like US English, UK English, or some other language. So all the text which has been used in the application will be stored in the a particular json file.
If a Warning message has been used in 100 places in the application, this particular variable in the json file would serve as the source for all the messages in the entire application.
If I want to do a text change, I don’t have worry about much in changing as well as testing. Just think of just a text change would have cost this much time, how about touching core functionalities in the code base. So avoid hard-coding whenever possible.
Building faster is pointless, when it isn’t build right. The art of saying No or YAGNI – “You Aren’t Gonna Need It” is an important skill in the software world. The software should not overflow with the features requested by everyone.
DRY – Instead of duplicating or repeating, just replace with abstraction – function or class
Keep your technical debt down, and deliver the deliverable on time.
We should decide which is emergency, if there is a bug in production which needs attention and a bug fix. That time we need to accept the debt and handle it in future. But we should make sure we should not consider a simple text change or minor new feature as technical debt.
To get latest updates you can follow or subscribe! #peace