Application analysis company Cast Software has this month released its Appmarq study, which it says is based on an examination of the structural quality and integrity of 686 applications currently in use by some 145 companies. With over 320 million lines of code to scrutinize, Cast's study has examined programming carried out in COBOL, Java, J2EE, and .NET environments and encompasses a range of industry verticals from banking and finance to manufacturing and the utility business.
Cast determines an application's structural quality to be a result of five factors (or pillars if you will): robustness — in terms of availability and ability to avoidance of outages; performance efficiency — dictated by speed of response, especially with regards to increasing workloads; security — in terms of protection against unwanted intrusion and data theft, etc.; transferability — in relation to the speed with which a new team can understand an app; and finally changeability — the ease (or lack of ease) of making changes to the application.
According to Cast software chief scientist Bill Curtis, "The effects of low structural quality and high technical debt are in the news almost every day. But these problems can be measured and managed." Speaking in an interview with Dr. Dobb's held this week in London England, Texan-born Curtis went on to explain the concept of "technical debt" much beloved by application analysis companies today. He said that software systems today are becoming so complex that (with the increased use of Agile methodologies) there will always be a certain amount of errors and bugs, but that fixing them now is always better than later, as technical debt incurs interest and so future repayments will always be higher.
Curtis, who coauthored the software application development Capability Maturity Model (CMM), has suggested that his company's study shows that there is no obvious decrease in application quality as a) an application gets larger and b) an application relies on more components from outsourced programmers or some other third-party resource. The reasons that this is so (he says) come down to modular construction in the application architectures in question.
In other findings, Cast has pointed to the perhaps unsurprising fact that public sector applications are still (as also shown in last year's study) the hardest to change once they are in a live production environment. Reasons for this, says Curtis, include the fact that the public sector will typically use a higher degree of application components (and complete applications) that have originated from contractors — and that the agreements which cover the supply of these apps does not typically provision adequately for ongoing maintenance. We await next year's survey with interest.