Read the corresponding blog post here http://www.ontechnicaldebt.com/blog/it-organizations-have-far-too-much-technical-debt/ New article published by IEEE discussing the estimation of technical debt, authored by experts at CAST Software

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 E
s6cur.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 35
s6cur.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 E
s6cur.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; cwe.mitre.org), 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 37
s6cur.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 e
s6cur.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 39
s6cur.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 e
s6cur.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 41
s6cur.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
castsoftware.com. 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 j.sappidi@castsoftware.com. references
1. S. McConnell, “Technical Debt,” blog, 1
Nov. 2007; http://blogs.construx.com/blogs/
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 a.szynkarski@castsoftware.com. 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.
castsoftware.com/resources/document/
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: www.computer.org/software/author.htm
for Inevitable Change, Addison-Wesley, 2011.
Further details: software@computer.org
www.computer.org/software
Selected CS articles and columns
are also available for free at
http://ComputingNow.computer.org.
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 E
s6cur.indd 42 10/4/12 2:35 PM