Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Estimating the Principal of an Applications Technical Debt


Published on

Read the corresponding blog post here …

Read the corresponding blog post here
New article published by IEEE discussing the estimation of technical debt, authored by experts at CAST Software

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. FOCUS: Technical Debt Estimating the simply as “violations”) known to have an unacceptable probability of contributing to severe opera- Principal of an tional problems (outages, security breaches, data corruption, and so on) or of contributing to high costs Application’s of ownership, such as excessive ef- fort to implement changes. • Principal is the cost of remediat- ing should-fix violations in produc- Technical Debt tion code (hereafter referred to as “TD-principal”). • Interest is the continuing costs at- tributable to should-fix violations Bill Curtis, Jay Sappidi, and Alexandra Szynkarski, CAST Software in production code that haven’t been remediated, such as greater maintenance hours and inefficient resource usage. • Technical debt is the future costs // A formula with adjustable parameters can attributable to known violations help in estimating the principal of technical in production code that should be debt from structural quality data. // fixed—a cost that includes both principal and interest. For the technical debt metaphor to be useful, its constructs must be measurable or at least estimable from measurable elements of software. For- tunately, we can estimate the viola- tions underlying TD-principal via tech- niques such as static analysis of the software’s nonfunctional, structural characteristics. 3 Violations of struc- Steve McConnell described opportunity costs, this article explores tural quality are often difficult to de- technical debt as including both inten- only the estimation of its principal. tect through standard testing but are tional and unintentional violations of frequent causes of severe operational good architectural and coding prac- The Technical Debt problems.4,5 tice1 —an expansion of Ward Cunning- Metaphor Facing limited application bud- ham’s original focus on intentional de- In embracing McConnell’s approach gets, IT organizations will never fix cisions to release suboptimal code to as the most comprehensive for com- all violations in an application. Tech- achieve objectives such as faster deliv- municating the costs and risks of poor nical debt estimates ought to only in- ery.2 By choosing debt as a metaphor, structural quality, we use the follow- clude should-fix violations in produc- Cunningham engaged a set of financial ing definitions for constructs estimated tion code. Nonetheless, the amount of concepts that can help executives think in this article: should-fix problems sometimes exceeds about software quality in business the budget available for remediation. terms. Although the concept of tech- • Should-fix violations are viola- Consequently, IT management must nical debt incorporates entities such tions of good architectural or cod- estimate the amount of technical debt as principal, interest, liabilities, and ing practice (hereafter referred to in its applications and then adjust the 34 I E E E S o f t w a r e | p u b l is h e d b y t h e I E E E c o m p u t e r s o c ie t y 0 74 0 -74 5 9 / 12 / $ 3 1. 0 0 © 2 0 12 I E E Es6cur.indd 34 10/4/12 2:35 PM
  • 2. Parameter values for three estimates of TD-principal. Table 1 Parameter values Variable Estimate 1 Estimate 2 Estimate 3 Violations that must be fixed High-severity violations 50% 100% 100% Medium-severity violations 25% 50% Low-severity violations 10% Hours to fix High-severity violations 1 hour 2.5 hours 10%—1 hour 20%—2 hours 40%—4 hours 15%—6 hours 10%—8 hours 5%—16 hours Medium-severity violations 1 hour 1 hour Low-severity violations 1 hour US$ per hour All violations 75 75 75 parameters in its estimates to deter- fix each violation, and the cost of la- Estimates from this equation pro- mine how much of that debt can be re- bor. We can measure or estimate each vide managers with ballpark figures for duced within the available budget. This of these variables to develop a formula assessing future maintenance costs, as evaluation helps prioritize the problems for computing TD-principal. The time well as for making investment decisions to remediate, as well as provides infor- to fix a violation, for example, could regarding structural quality improve- mation about the amount and types of be available from historical effort data. ments to reduce future costs and risks. risk remaining in an application. The cost to fix violations can be set to Although we present several choices the average burdened rate for the devel- for parameter values here, IT organiza- A Method for Estimating opers assigned to the activity. Using the tions should calibrate these parameters TD-Principal three variables, the equation for esti- to their own experiences to obtain the There’s no exact measure of an appli- mating TD-principal is most relevant estimates. cation’s TD-principal because its cal- We used three different settings for culation should be based only on the TD-principal = ((S high-severity these parameters (see Table 1) to ex- should-fix violations, some of which violations) × (percentage to be fixed) plore their effects on TD-principal esti- might be undetected. However, mod- × (average hours needed to fix) mates. Although burdened hourly rates ern software analysis and measure- × (US$ per hour)) + ((S medium- can vary by experience and location, we ment technology lets us estimate TD- severity violations) × (percentage to found that a rate of US$70 to $80 per principal from counts of detectable be fixed) × (average hours needed to hour reflects the average costs for many violations. Thus, we can estimate TD- fix) × ($ per hour)) + ((S low-severity IT organizations, especially where they principal as a function of three vari- violations) × (percentage to be fixed) have a mix of on- and offshore opera- ables—the number of should-fix vio- × (average hours needed to fix) × ($ tions. Consequently, we used the same lations in an application, the hours to per hour)). hourly rate in all three estimates. In N o v e m b e r / De c e m b e r 2 0 1 2 | IEEE S o f t w a r e 35s6cur.indd 35 10/4/12 2:35 PM
  • 3. FOCUS: Technical DebT Language parsers Application analysis Detected violations Quality characteristics Oracle PL/SQL Expensive operation in loop Sybase T-SQL Static vs. pooled connections Complex query on big table Performance SQL Server T-SQL IBM SQL/PSM Large indices on big table C, C++, C# Pro C Cobol Empty CATCH block Evaluation of 1,200+ Uncontrolled data access CICS coding and Robustness Visual Basic Poor memory management architectural rules Opened resource not closed VB.Net ASP.Net Java, J2EE SQL injection JSP Cross-site scripting XML Application Security Buffer overflow HTML metadata Uncontrolled format string JavaScript VBScript PHP Unstructured code PowerBuilder Misuse of inheritance Oracle Forms Lack of comments Transferability PeopleSoft Violated naming convention SAP, ABAP Netweaver Tibco Highly coupled component Business Objects Duplicated code Universal analyzer Index modified in loop Changeability for other languages High cyclomatic complexity FiGURe 1. CAST Software’s Application Intelligence Platform. This technology analyzes all the source code of an application and reintegrates the metadata across languages to detect violations of more than 1,200 rules of good architectural and coding practice. These violations are aggregated into measures of several quality characteristics, which are provided to both management and the developers. each estimate, we varied the percentage the time to fi x in estimate 3 as a dis- The organizations that submitted of violations at each severity level that tribution that might be more realistic these applications were primarily from would be prioritized for remediation, based on data observed in several IT the US, Europe, and India. Because addressing fewer severity levels in esti- organizations. there’s no rigorous characterization of mates 2 and 3. the global population of business ap- The calculation in estimate 1 as- the Sample and data plications, it’s impossible to assess the sumes that all violations would be fi xed The data reported here are drawn from generalizability of results drawn from within one hour. Based on industry the Appmarq benchmarking reposi- this sample. Nevertheless, these results data, this is an extremely conservative tory maintained by CAST Software. 6 emerge from what we believe to be the number, which we chose to provide a For this exploration, we drew a sam- largest sample of applications to be lower bound for TD-principal. In esti- ple from the repository of 700 applica- statically analyzed for structural qual- mate 2, we varied the hours needed for tions submitted by 158 organizations ity characteristics across different lan- fi xing within each severity category, for the analysis and measurement of guages and technology platforms. The assuming that high-severity violations their structural quality characteristics. industries from which we received these would contain proportionately more vi- The applications in this sample cumula- applications included fi nancial services, olations and require more hours to fi x. tively contained 357 MLOC. We didn’t insurance, telecommunications, manu- Because there are few published dis- accept applications into the sample if facturing, energy, IT consulting, retail, tributions of hours to fi x, we modeled they consisted of fewer than 10 KLOC. and government. Because of criteria 36 I E E E S o f t w a r E | w w w. c o m p u t E r . o r g / S o f t w a r Es6cur.indd 36 10/4/12 2:35 PM
  • 4. used by most companies for submit- the number of opportunities for a rule that can be computed from the source ting applications to analysis, we believe to be triggered and the percentage of code, some quality characteristic names this sample is biased toward business- times that rule was violated. Each vio- used here differ based on the content critical applications. lation is weighted by its severity and analyzed and the meaningfulness of the We analyzed these applications us- aggregated to the application level. (Us- names to management. The AIP evalu- ing CAST’s Application Intelligence ers can adjust severity weights for each ates anywhere from 176 to 506 rules Platform (AIP),7 which analyzes an en- violation to match local priorities, but for each quality characteristic, and tire application using more than 1,200 the results we present here are based on some rules are evaluated for more than rules to detect violations of good ar- the original weights.) The AIP provides one characteristic. chitectural and coding practice. We a series of management reports and a drew these rules from software engi- portal to guide developers to locations Calculating TD-Principal neering literature, repositories such as in the source code where specific viola- We calculated three estimates of TD- the Common Weakness Enumeration tions can be remediated. The manage- principal for each of the 700 applica- (CWE;, online discus- ment report aggregates violation scores tions using equations with the three sion groups of structural quality prob- into measures for the five quality char- sets of parameter values listed in Table lems, and customer experience as re- acteristics shown in Figure 1: 1. The first row of Table 2 shows de- ported from defect logs and application scriptive statistics for the distribution architects. As an example, security- • robustness, the stability or re- of these estimates across the full sample related violations would include SQL silience of an application and its for each of the three estimating equa- injection, cross-site scripting, buffer ability to avoid outages or recover tions. The differences among means for overflows, and other violations from quickly from them; these three estimates are large, rang- the CWE. • performance efficiency, the appli- ing from $3.61 in estimate 1 to $15.62 The AIP begins by parsing an ap- cation’s responsiveness and its effi- in estimate 3. This large difference in plication’s entire source code at build cient use of resources; mean values reveals how sensitive the time to develop a representation of the • security, an application’s abil- resulting estimates of TD-principal are elements from which the application is ity to prevent unauthorized in- to values selected for the parameters. built—its data flows, class hierarchies, trusions and protect confidential Although almost any result can be ob- transaction paths, calling relationships, information; tained by manipulating parameters, and so on. The AIP includes parsers for • transferability, the ease with which the critical lesson is the importance of the 28 languages listed in Figure 1, and a new team can understand the ap- adjusting parameters to fit local priori- a universal analyzer provides a par- plication and quickly become pro- ties for fixing violations and matching tial parse of languages that don’t have ductive in working with it; and historical data regarding the times and dedicated parsers. The metadata pro- duced from this parsing is reintegrated across languages and platforms to pro- vide a full view of the application. The Integrating the metadata lets us consider AIP uses several techniques to detect the full application context in detecting violations of its architectural and cod- violations and reducing false positives. ing rules (examples of which are under the Detected violations column in Fig- ure 1). Integrating the metadata lets us consider the full application context in • changeability, an application’s abil- costs for doing so. Only then can such detecting violations and reducing false ity to be easily modified and avoid estimates provide useful information positives. For instance, to determine the injection of new defects. about TD-principal. whether a table being called by a loop Table 2 also presents descriptive sta- with an expensive operation violates We selected these characteristics tistics for the three estimating equa- performance efficiency rules, we need after reviewing ISO/IEC 9126.8 How- tions for seven of the languages used to know the context of whether the ta- ever, because the quality character- in the 700 applications. Because mod- ble is large or small. istics in 9126 and its successor, ISO/ ern applications are frequently devel- AIP scoring begins by detecting IEC 25010,9 aren’t defined to a level oped in several languages, we split each N o v e m b e r / De c e m b e r 2 0 1 2 | IEEE S o f t w a r e 37s6cur.indd 37 10/4/12 2:35 PM
  • 5. FOCUS: Technical Debt Estimated US dollars per LOC of TD-principal by language.* Table 2   Mean Median Minimum 25th 75th quartiles Maximum Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 All 3.61 10.26 15.62 2.79 7.94 11.77 0.06 0.01 0.21 1.13 3.49 5.91 38.08 132.74 278.00 5.25 14.45 18.28 apps (n = 700)** .NET 3.09 12.29 28.34 2.37 10.20 22.32 0.96 0.49 1.18 0.84 3.36 8.02 16.52 73.00 175.63 4.98 19.06 43.01 (n = 63) SAP- 0.43 1.90 4.29 0.41 1.73 3.79 0.05 0.20 0.41 0.27 1.20 2.47 1.42 6.89 16.31 0.57 2.50 5.85 ABAP (n = 72) C 2.62 7.65 17.12 2.18 6.46 14.62 0.02 0.01 0.33 0.83 2.93 4.36 12.82 31.89 75.64 3.18 9.73 21.69 (n = 44) C++ 4.33 12.95 26.77 2.41 7.83 14.52 0.02 0.01 0.06 1.55 4.51 8.80 38.08 132.91 278.00 4.41 10.53 22.25 (n = 30) Java 5.42 14.68 19.82 5.13 13.66 16.18 0.07 0.23 0.50 2.40 8.19 11.94 49.72 253.03 608.68 7.48 18.52 21.33 EE (n = 474) Oracle 4.57 21.16 49.52 1.12 3.87 7.58 0.49 1.13 1.19 0.99 3.24 5.82 30.23 151.93 366.65 5.92 27.88 66.70 Forms (n = 45) Visual 2.93 9.83 18.91 2.58 8.37 15.29 0.68 2.77 4.01 1.16 3.45 6.10 12.14 45.01 93.59 3.20 11.21 20.69 Basic (n = 16) *Maximums, minimums, and quartiles for individual language distributions can be greater than or less than the figures for the total sample because the numerator and denominator change when applications are divided into language-specific subsystems. **Because some applications contain multiple languages, the sum of the samples for the languages is greater than 700. application into subsystems written large. For instance, the mean for esti- explain this large spread. However, it in different languages. We produced mate 1 ranges from a low of $1.90 per might also be affected by the different estimates using each of the three esti- LOC for Advanced Business Applica- uses to which these languages are ap- mating equations for each subsystem tion Programming (ABAP) to a high plied, ranging from customizing an ex- within the seven languages in Table 2. of $21.16 per LOC for Oracle Forms isting vendor package with ABAP to The differences in TD-principal es- (F = 10.63; p .0001). Structural dif- developing an entire application with timates among different languages are ferences in the languages could partly Java EE or C++. We also can’t rule out 38 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r es6cur.indd 38 10/4/12 2:35 PM
  • 6. Percentage of technical debt associated with each quality characteristic. Table 3 Robustness Performance Security Changeability Transferability Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 Est. 1 Est. 2 Est. 3 All apps 18% 19% 18% 5% 1% 1% 7% 3% 3% 30% 37% 39% 40% 40% 39% (n = 700) .NET 17% 16% 15% 8% 6% 7% 9% 13% 13% 36% 38% 39% 30% 27% 26% (n = 63) ABAP 41% 41% 43% 2% 2% 0% 0% 0% 0% 9% 13% 10% 48% 44% 47% (n = 72) C 13% 10% 9%  3% 2% 2% 4% 3% 3% 35% 40% 41% 45% 45% 45% (n = 44) C++ 7% 7% 5% 2% 1% 2%  7% 5% 0% 44% 45% 46% 40% 42% 47% (n = 30) Java EE 12% 21% 30% 3% 5% 8%  5% 10% 16% 16% 22% 28% 63% 42% 18% (n = 474) Oracle 32% 34% 35% 7% 6% 8% 1% 1% 0% 13% 18% 44% 47% 41% 13% Forms (n = 45) Visual 23% 23% 22% 3% 3% 3% 6% 9% 10% 34% 35% 31% 34% 30% 34% Basic (n = 16) sample-specific factors affecting these TD-principal for each application indi- TD-principal estimates strategically, differences because other research, con- vidually—or, at most, for applications management must establish its struc- trary to our results, found technical being developed under similar condi- tural quality objectives and allocate debt to be the highest for ABAP.10 tions for similar uses—rather than using remediation resources accordingly.11 The variance in estimates within a an average estimate across all applica- Our data allow us to estimate the TD- single language category is quite large. tions within a language category. Identi- principal associated with the violations For instance, among Java EE applica- fying the factors behind these variances that constitute each of the five quality tions, estimates of TD-principal using in operational environments can reveal characteristics we defined in the section the parameters in estimate 2 ranged opportunities for large reductions in called “The Data and Sample.” from $0.23 per LOC to $253.03 per software costs. The first row in Table 3 shows the LOC. The distributions are all positively percentage of total violations constitut- skewed, with most languages having TD-Principal by Quality ing TD-principal for each of the five large interquartile ranges. Consequently, Characteristic quality characteristics using violation to be used effectively in management de- The violations of structural quality parameters for each of the three esti- cisions regarding cost of ownership or from which TD-principal is estimated mates. For the full Appmarq sample, investments in structural quality, IT or- can represent different types of threats 70 percent of the TD-principal esti- ganizations should measure and analyze to the business or costs to IT. To use mated in this sample was contained in N o v e m b e r / De c e m b e r 2 0 1 2 | IEEE S o f t w a r e 39s6cur.indd 39 10/4/12 2:35 PM
  • 7. FOCUS: Technical Debt the IT cost–related quality characteris- violations. (We discuss this more in all of the violations. For instance, the tics of changeability and transferability, the next section.) average number of violations in Java whereas only 30 percent was contained The quality characteristic results EE for the high-severity violation of us- in the business risk factors of robust- suggest that the analysis and measure- ing fields from other classes was 1,173 ness, performance efficiency, and secu- ment of TD-principal can be used in per application. rity. We can’t determine from the data conjunction with structural quality Second, a consistent problem across whether IT organizations are spending priorities to guide management deci- all the languages except Java EE is com- more time eliminating TD-principal re- sions about how to allocate resources plexity represented as violations of ei- lated to business risk or, alternatively, for reducing business risk and IT cost. ther a module-calling structure with whether TD-principal is created most For many IT managers and executives, high fan-out to external components often in violations associated with IT trying to make decisions about retir- or a control flow with high internal cost–related factors. ing TD-principal at a global level is complexity. These violations are often The remaining rows in Table 3 indi- overwhelming, and they struggle to traces of the tradeoffs that led Cun- cate that the relative percentages of vio- visualize what the expected payoff ningham to make his original observa- lations from each of the quality charac- will be. However, when managers can tion regarding technical debt. 2 Under- teristics constituting TD-principal were analyze TD-principal by its constitu- standing the tradeoffs between these generally consistent across language ent quality characteristics, they can violations and either operational per- categories and estimating parameters. set specific reduction targets based on formance or maintenance costs are crit- However, there were two notable varia- strategic quality priorities with a bet- ical to helping managers set strategic tions. First, robustness violations ac- ter understanding of the cost or risk structural quality objectives. counted for relatively higher percent- reduction benefits. Third, the large percentage of TD- ages of ABAP’s and Oracle Forms’ principal accounted for by the cost-re- TD-principal; security and changeabil- Analysis of Violations lated quality characteristics of change- ity violations accounted for relatively We can gain deeper insight into struc- ability and transferability in Table 3 lower percentages. These differences tural quality by investigating the types is reflected in Table 4 by the frequen- could relate to how these languages are of violations that create TD-principal. cies of complexity-related violations, used in customizing their associated Table 4 presents the five most frequent as well as violations of practices that packaged software. violations included in TD-principal and aid comprehension. These cost-related Second, as the estimating param- the frequency of their detection across violations are especially prevalent in eters for violations shifted toward applications for each of the seven lan- Java, accounting in part for its higher TD-principal cost compared to other languages. Because these tend to be categorized as medium-severity viola- Managers can set specific tions, managers must weigh the cost reduction targets based tradeoff between remediating these on strategic quality priorities. violations and the accruing interest from increased effort to understand the code. E high-severity violations in estimates guages we studied. 2 and 3, the percentage of viola- These results are difficult to com- ven when measured with a con- tions shifted from transferability to- pare at the application level because servative formula, the amount ward other quality characteristics many violations are defined specific of technical debt in most busi- for Java EE and Oracle Forms. This to each language. Nevertheless, sev- ness applications is formidable. For shift likely resulted from the relatively eral themes emerge from these results. instance, even when applying the con- high proportion of comment-related First, if we divide the frequencies of servative parameters in estimate 1, the violations for these languages that the individual violations by the number average application is estimated to have were eliminated from TD-principal of applications in which they were de- $361,000 of TD-principal for each calculations as the estimating param- tected, we find that the number of oc- 100 KLOC. When the more realistic eters shifted toward higher-severity currences per application is large for parameters of estimate 3 are applied, 40 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r es6cur.indd 40 10/4/12 2:35 PM
  • 8. The top five violations contributing to TD-principal by language. Table 4 Language Violation Frequency .NET Avoid uncommented methods 203,651 (n= 63) Avoid declaring public class fields 152,972 Avoid artifacts with high fan-out 84,580 Avoid classes with a high lack of cohesion 56,486 Avoid instantiations inside loops 16,309 ABAP Avoid artifacts with a complex Select clause 61,376 (n = 72) Avoid artifacts with high internal complexity 61,184 Avoid artifacts with high fan-out 43,428 Avoid artifacts with high depth of code 20,061 Avoid artifacts with high fan-in 16,490 C Avoid undocumented functions 56,027 (n = 44) Avoid artifacts with high internal complexity 32,943 Avoid functions with SQL statement including subqueries 30,153 Never use strcpy() function—use strncpy() 29,332 Never use sprintf() function or vsprintf() function 21,608 C++ Avoid undocumented functions, methods, constructors, destructors 267,861 (n = 30) Avoid data members that are not private 182,076 Avoid unreferenced methods 73,888 Avoid using global variables 47,834 Avoid artifacts with high internal complexity 18,065 Java EE Avoid methods missing JavaDoc comments 4,028,727 (n = 474) Avoid methods missing appropriate JavaDoc @param tags 3,227,014 Avoid methods missing appropriate JavaDoc @return tags 3,018,182 Avoid private fields missing JavaDoc Comments 1,737,620 Avoid using fields (nonstatic final) from other classes 556,046 Oracle Forms Avoid objects without Comment property 1,717,616 (n = 45) Avoid artifacts with high fan-out 68,213 Avoid artifacts with high internal complexity 32,411 Avoid artifacts with high fan-in 20,616 Use based data blocks naming convention—represented table 9,866 Visual Basic Avoid undocumented functions and methods 45,680 (n = 16) Avoid using global variables 32,258 Avoid unreferenced functions and methods 23,675 Avoid direct usage of database tables 12,885 Avoid artifacts with high internal complexity 7,143 executives will likely dismiss the esti- estimates we present in this article as the number of applications grows mated size of TD-principal as exces- as industry benchmarks. This explo- in the Appmarq repository. Neverthe- sive. However, when large estimates ration of estimates for TD-principal less, these results provide a good start- result from accurate parameters for demonstrates that these estimates are ing point for exploring TD-principal, an organization’s hours to fix and cost extremely sensitive both to the as- and one that can be adjusted based on per hour, then the percent of violations sumptions made in parameterizing the different assumptions about the pa- to be fixed can be varied to determine equation and the different types of rameters used. When developed with how many violations can be remediated languages to which they are applied. professional discipline, estimates of within existing budgets and which vio- These estimates could also shift with TD-principal can be a powerful tool to lations to prioritize. changes in the mix of application char- aid management in understanding and We urge caution in interpreting the acteristics in each language category controlling IT costs and risks. N o v e m b e r / De c e m b e r 2 0 1 2 | IEEE S o f t w a r e 41s6cur.indd 41 10/4/12 2:35 PM
  • 9. FOCUS: Technical DebT The next step in our exploration of abOUT The aUThORS TD-principal is to provide individual bill CUrtiS is senior vice president and chief scientist of CAST Soft- ratings for the effort to fi x each of the ware and heads CAST Research Labs. His research interests include 1,200+ violations. These effort ratings software productivity and quality, empirical software engineering, will be further adjusted by the number organizational maturity models, and a formal proof that the Veer-T triple option can execute in linear time. Curtis received a PhD from Texas of components involved in fi xing the Christian University. He’s an IEEE Fellow. Contact him at b.curtis@ violation and the complexity of each component. This refi nement will make the calculation of TD-principal more granular and could provide better in- JAY SAPPidi is the senior director of product marketing at CAST dicators of components most in need Software and a senior director in CAST Research Labs. His research of refactoring. interests include predictive analytics for software risk management through software analysis, measuring the impact of technical quality on developer productivity, and comparative analysis of application technical quality across technologies. Sappidi received an MBA from the MIT Sloan School of Management. Contact him at references 1. S. McConnell, “Technical Debt,” blog, 1 Nov. 2007; stevemcc/archive/2007/11/01/technical AleXAndrA SZYnKArSKi is a research associate in CAST -debt-2.aspx. Software’s Research Labs. Her interests include structural quality 2. W. Cunningham, “The WyCash Portfolio benchmarks and measuring software performance trends on the global Management System,” ACM SIGPLAN application development community. Szynkarski received an MS in in- OOPS Messenger, vol. 4, no. 2, 1993, pp. 29–30. ternational business administration from the Institut Administration des Entreprises de Nice. Contact her at 3. B. Curtis, J. Sappidi, and A. Szynkarski, “Esti- mating the Size, Cost, and Types of Technical Debt,” Proc. 3rd Int’l Workshop Managing Technical Debt, IEEE CS, 2012, pp. 49–53. 4. D. Spinellis, Code Quality: The Open Source Perspective, Addison-Wesley, 2006. 5. M.T. Nygard, Release It!, Pragmatic Book- shelf, 2007. 6. J. Sappidi, B. Curtis, and A. Szynkarski, Call for Articles CAST Report on Application Software Health, tech. report, CAST Software, 2011. 7. CAST Application Intelligence Platform, tech. report, CAST Software, 2008; www. zbrochures/cast-ai-platform. IEEE Software seeks practical, readable 8. ISO/IEC 9126, Software Engineering— Product Quality, Int’l Org. for Standardi- articles that will appeal to experts and nonexperts zation, 2001. alike. The magazine aims to deliver reliable 9. ISO/IEC Std. 25010, Systems and Software Engineering—Systems and Software Quality information to software developers and managers to Requirements and Evaluation (Square)—Sys- tem and Software Quality Models, Int’l Org. help them stay on top of rapid technology change. for Standardization, 2011. Submissions must be original and no more than 4,700 10. J. de Groot et al., “What Is the Value of Your Software?,” Proc. 3rd Int’l Workshop Man- words, including 200 words for each table and figure. aging Technical Debt, IEEE CS, 2012, pp. 37–44. 11. C. Sterling, Managing Software Debt: Building Author guidelines: for Inevitable Change, Addison-Wesley, 2011. Further details: Selected CS articles and columns are also available for free at 42 I E E E S o f t w a r E | w w w. c o m p u t E r . o r g / S o f t w a r Es6cur.indd 42 10/4/12 2:35 PM