June 29, 2017
Enterprises spend a considerable amount of time and resources in making sure an application being launched at the production level is bug-free. However, the attention given to the quality of the software code is minimal.
This is where major enterprises falter. The structural quality of an application is an indicator of the soundness of application architecture and code, which cannot be correctly measured by just the right functioning of the application, according to the business’ rules.
Internal and external code reviews have been reduced to a mere formality assuming that the developers are at a level that merits implicit trust where coding quality is concerned. Normally, the application must be developed in accordance with the best coding practices and adhere to the basic requirements of a good software release.
It is necessary to note that the experience of a developer — meaning years spent in coding — is not always an indicator of expertise. Regardless of the testimonials that the development team has received over the years, each application code written by them (whether in-house or through outsourcing) must be subjected to rigorous quality checks.
The main factors that should be taken into account are:
1. Technical debt
Bugs have a way of escaping development and testing cycles to manifest themselves in the production environment. The cost required to fix these bugs (errors) that remain in the code at the production level is called technical debt. Interest is incurred in the form of extra effort that is required to handle production level errors due to structural flaws in the application code.
Technical debt is calculated as:
Technical Debt = (0.1*Low Severity Violations + 0.25*Medium Severity Violations + 0.5*High Severity Violations)*No. of Hours to Fix*Cost/Hour.
Even if an assumption is made that each problem would take one hour to fix at a cost of $75 per hour, it gets higher at the production level. On an average, a 374,000 line application code and incur $1 million as technical debt.
The security of an application is measured by attributes of its code that make it less susceptible to the risk of data intrusion.
Mainframe applications are found to be more secure than the network connected applications because they are less exposed to security threats that impact Web-facing applications.
Enterprises often focus only on the security aspects that must be addressed by compliance regulations within the industry verticals while application code remains vulnerable to security threats either because of human errors or platform dependencies.
These are the attributes that make an application flexible to required changes, and faster to modify. Changeability is one of the primary drivers of TCO (total cost of ownership) of an application. Thus, there is a significant investment overhead if the application has a low changeability score.
It is observed that changeability scores are very low in government sector applications because the tenders are given to multiple vendors who fail to develop applications that are developed on the same platforms using the same development languages. Apart from the Government sector, there is little difference in the changeability scores in in-house and outsourced applications. It significantly depends on the development technology and the skill of the developer working on the application.
4. Performance and robustness
Performance is measured by the responsiveness and efficiency of an application while robustness is measured by the application’s stability and ability to reduce defect-creeps when modified.
Automated performance testing tools make it easy to identify performance related problems. They indirectly provide an idea of code level issues by indicating bottlenecks and critical failures at certain checkpoints. Thus, applications using the best performance testing tools will score high on the performance scale.
Robustness of an application is dependent on its security and changeability score. There is seldom any fluctuation in the robustness if both these scores are on the higher side. It is important to note that a higher performance score does not imply a parallel robustness score.
It is a flawed assumption that larger application size indicates lesser structural quality. Modularity is measured by the ability of an application code to provide abstraction and isolation such that changes to one module will not necessarily affect another module unless required by the application’s business rules.
Modularity score is much higher in object-oriented languages like Java EE and .Net while it is considerably lower in mainframe languages like COBOL.
The structural quality of a code is independent of its functioning, which may be excellent according to the business’ rules of the application. It is necessary to evaluate every application code on the basis of the above points to ensure that the enterprise is not incurring millions of dollars of technical debt.
Jessica Cyrus is a QA tester and content writer in Nexsoftsys which is an Offshore Software Development Company in India working for the USA. Jessica has MS Degree and she has content writing skills.