=Paper=
{{Paper
|id=Vol-1771/paper10
|storemode=property
|title=When, Why and for Whom do Practitioners Detect Technical Debt? An Experience Report
|pdfUrl=https://ceur-ws.org/Vol-1771/paper10.pdf
|volume=Vol-1771
|authors=Norihiro Yoshida
|dblpUrl=https://dblp.org/rec/conf/apsec/Yoshida16
}}
==When, Why and for Whom do Practitioners Detect Technical Debt? An Experience Report==
https://ceur-ws.org/Vol-1771/paper10.pdf
1st International Workshop on Technical Debt Analytics (TDA 2016)
When, why and for whom do practitioners detect
technical debt?: An experience report
Norihiro Yoshida
Nagoya University
Email: yoshida@ertl.jp
Abstract—Code cloning is one of the most well-known code- II. P ROJECT I NSTANCES
level technical debts. In this paper, I discuss when, why and for
whom practitioners detect code clones based on my experience of Case A: The company of Case A is a Japanese con-
industry/university collaboration. At first, I introduce five project glomerate company. A division of this company has owned
instances based on my experience. Next, I identify elements of and maintained two large-scale legacy systems written in the C
the context model of a software maintenance project. After that,
I discuss the impact of the context of a software maintenance language. One of the systems is for an electric power company,
project on technical debt. and the another one is for a railway company. The developers
in the division expect to maintain the code in the next decade.
I. I NTRODUCTION Since they plan to perform large-scale maintenance soon, they
would like to reduce the amount of the code by merging code
The results of empirical studies of software engineering clones. They believe that they will be able to reduce the cost
usually depend on the context (e.g., programming language. of maintaining the code once clones in the code are merged.
size of product, development process) of a software develop- Case B: An another division of the company in Case A
ment [1]. Studies of technical debt [2] also depend on it. For provides service for reducing legacy code written in COBOL.
example, if a development team expects to perform long-term So far, the software system often has dependencies on a
software maintenance, it proactively refactors source code. specific vendor for products and services and the customer
Conversely, if it is commissioned to maintain the source code of the system has been unable to use another vendor without
for a customer and do not expect to touch it after the project, substantial switching cost. Recently, many customers would
it is unmotivated to perform refactoring. like to migrate from such a vendor lock-in system to a
So far, much research has been done on the empirical studies new system that uses open source software (e.g., Linux,
of technical debt [3], [4], [5]. The results of those studies PostgreSQL). Before the migration, the customers would like
sometimes tell different stories. For instance, several studies to reduce the existing source code and reduce the maintenance
successfully detected defects that are caused by maintaining cost.
code clones [6], [7]. On the other hand, other studies reported Case C: The company of Case C is also a conglomerate
that code clones are harmless for software maintenance [8], company. This company has owned and maintained large-scale
[9]. Such inconsistency can be caused by context differences software systems for smartphones. The code is written in the C
between target projects in the empirical studies of technical language. The amount of code has rapidly increased recently.
debt. For a deeper understanding of technical debt, the em- The persons in charge worry about inconsistencies among code
pirical software engineering community has to identify the clones and would like to perform simultaneous modifications
context model of a software maintenance project. correctly.
In this position paper, I focus on code cloning which is one Case D: The company of Case D is a Japanese system
of the most well-known examples of code-level technical debt integration company. In Case D, several subcontractors con-
[6], [7], [10]. At first, I introduce the context instances when tribute to the project, and each of them has been in charge of
developers focus on code cloning according to my experiences a part of the development. Each subcontractor has maintained
in industry/university collaboration. After that, I discuss ele- subcontractor-owned code for the part and delivered it after
ments of the context model of a software maintenance project implementation phase. The project manager in case D would
and the impact of those elements on technical debt. like to know the location of code clones in large-scale source
The remainder of this position paper is organized into the code and avoid the amount increases.
following sections. Section II introduces the context instances Case E: The company of Case E is a Japanese provider
when developers focus on code cloning according to my of information technology services and products. Case E is
experiences in industry/university collaboration. Next, Section a maintenance project for medium-scale source code that is
III discusses elements of the context model of a software owned by this company. The developers in Case E would like
maintenance project and the impact of those elements on to avoid that the amount of code clones increases and detect
technical debt. Section IV reviews related work and finally, newly-created or modified clones on the fly. They would like
Section V concludes with possible future work. to use a system for reporting such clones daily.
64
1st International Workshop on Technical Debt Analytics (TDA 2016)
Table I summarizes the characteristics of above project a customer, the customer tends to focus on the amount of
instances in terms of not only when, why and for whom technical debt and does not consider a strategy to deal with
practitioners detect clones but also language and owner/scale each of them. The case that technical debt was detected in
of a code base. subcontractor-owned code by a project manager is very similar
to the above case. The project manager tends just to focus on
III. D ISCUSSION
the amount of technical debt and does not consider a strategy
A. Context Element to deal with each of them. In these cases, the decrease of
According to Table I in Section 2, we found that the context the maintenance cost is expected to be limited even if many
model of software maintenance projects includes the following of the technical debt are eliminated. Researchers have to be
elements for the empirical software engineering of technical careful about persons in charge of checking detected technical
debt: debt and the owner of the code when they compare or discuss
• When is technical debt detected? (e.g., before releasing empirical studies of the technical debt.
a version, daily build) d) Target: The expressiveness of a programming lan-
• Why are stakeholders motivated to detect technical debt? guage strongly affects the strategy to deal with code smells
(e.g., refactoring, clone prevention) [11], [12]. For example, Java has many language features
• Who is expected to check detected debt? (e.g., devel- for refactoring, but C has only a few such ones. Therefore,
opment team, customer who would like to maintain the researchers have to be careful about a programming language
system, project manager) that is used in the project when they compare or discuss
• Who is the owner of the code? (e.g., company that empirical studies of the technical debt. The size of a code
developers who detect technical debt own, customer who base also is considered to affect the number of code smells.
would like to maintain the system) Keeping the consistency of large-scale source code is difficult.
• What kind of the code? (e.g., language, legacy/new, long- For example, large-scale source code tends to include many
term/short-term maintained) code clones and it is difficult to keep the consistency of the
code clones [6], [13].
B. Impact of Context on Technical debt
Hereafter, I discuss the impact of the context elements in IV. R ELATED W ORK
Section III-A on technical debt.
a) When: In order to detect technical debt as much as Defect-prone clone is regarded as a serious technical debt.
possible, it is most appropriate to monitor all of the code Many empirical studies have focused on the relationship
modifications on the fly because many refactoring operations between code cloning and defects. Several researchers inves-
are expected to be completed before a commit. Second best tigated the relationship between code clones and defects in
is detecting technical debt from all of the committed versions source code. Rahman et al. reported that the great majority of
in a version control system. A released version is expected defects are not significantly associated with code clones [8].
to include a fewer number of technical debt compared to Also, Sajnani et al. reported that code clone has considerably
a committed version because developers not only tend to less, and less problematic, bug patterns [9]. Mondal et al.
introduce technical debt but also try to reduce them. When compared the defect-proneness of different type of code clones
researchers compare or discuss empirical studies of technical [14]. Islam et al. reported that a considerable proportion of the
debt, they have to be careful about the timing when technical code clones was able to contain replicated bugs [15].
debt are detected. The inconsistency among code clones is a clue to the
b) Why: The result of an empirical study of technical detection of defect-prone clones. Li et al. proposed an a
debt is expected to depend on the strategy to deal with it tool, CP-Miner that uses data mining techniques to efficiently
in the development. If developers considered refactoring as a identify copy-pasted code in large software suites and detects
solution to code clones, the number of the code clones tends copy-paste defects based on naming inconsistency among code
to be small. Conversely, if developers considered to keep the clones [16]. Jiang et al. proposed an approach to detecting
consistency among code clones and left consistent clones as clone-related defects based on inconsistencies among clones
they are, the number of code clones is larger than the previous [6]. Juergens presented the results of a large-scale case study
case. Researchers should try to find out the strategy to deal that was undertaken to find out if inconsistent changes to
with technical debt in the development and the purpose of it. cloned code can indicate defects [13]. They not only found
c) For Whom and Owner: In the case that technical that inconsistent changes to clones are very frequent but also
debt was detected in company-owned code by a maintenance identified a significant number of defects induced by such
team, it may have carefully considered a strategy to deal with changes.
each of the technical debts for maintenance in the future. In Change-prone code is a clue to the detection of technical
this case, many of the detected technical debts are expected debt. Several researchers investigated the change-proneness of
to be eliminated successfully, and the maintenance cost of code clones. Hotta et al. reported that the presence of duplicate
the code is also expected to reduce. Conversely, in the case code does not have a negative impact on software evolution
that technical debt was detected in customer-owned code for [17]. Harder and Göde reported that clone stability varies
65
1st International Workshop on Technical Debt Analytics (TDA 2016)
TABLE I
C OMPARISON OF P ROJECT I NSTANCES
Case When Why for Whom Owner Target
A before large-scale maintenance refactoring maintenance team company large-scale legacy C code
B before legacy modernization refactoring customer customer large-scale legacy C/COBOL code
C during maintenance consistency management maintenance team company large-scale legacy C code
D after implementation phase prevention project manager subcontractor large-scale legacy C/C+ code
E everyday during maintenance prevention maintenance team company medium-scale legacy Java code
depending on the clones characteristics, the corresponding supported by JSPS KAKENHI Grant Numbers JP26730036
project environment, and over time [18]. and JP16K16034.
Code-level technical debt is not limited to code cloning.
Yamashita and Moonen investigated the relationship between R EFERENCES
code smell and maintainability [3], [4]. They investigated the
[1] B. A. Kitchenham, S. L. Pfleeger, L. M. Pickard, P. W. Jones, D. C.
capability of 12 code smells to reflect actual maintenance prob- Hoaglin, K. E. Emam, and J. Rosenberg, “Preliminary guidelines for
lems [3]. They also empirically investigated the interactions empirical research in software engineering,” IEEE Transactions on
amongst 12 code smells and analyze how those interactions Software Engineering, vol. 28, no. 8, pp. 721–734, Aug 2002.
[2] P. Kruchten, R. L. Nord, and I. Ozkaya, “Technical debt: From metaphor
relate to maintenance problems [4]. to theory and practice,” IEEE Software, vol. 29, no. 6, pp. 18–21, Nov
Refactoring is the most well-known technique aiming to 2012.
reduce code-level technical debt. Several empirical studies [3] A. Yamashita, “Assessing the capability of code smells to explain
maintenance problems: an empirical study combining quantitative and
have been done on the relationship between code smells and qualitative data,” Empirical Software Engineering, vol. 19, no. 4, pp.
refactoring. Stroggylos and Spinellis investigated the impact of 1111–1143, 2013.
refactoring on quality metrics [19]. Bavota et al. investigated [4] A. Yamashita and L. Moonen., “Exploring the impact of inter-smell
relations on software maintainability: An empirical study,” in Proc. of
the extent to whether refactorings executed on classes exhibit- ICSE, 2013, pp. 682–691.
ing code smells and able to remove code smells [20]. The re- [5] M. Tufano, F. Palomba, G. Bavota, and R. Oliveto, “When and why your
sult shows that 42% of refactoring operations were performed code smell starts to smell bad,” in Proc. of ICSE, 2015, pp. 403–414.
[6] L. Jiang, Z. Su, and E. Chiu, “Context-based detection of clone-related
on code entities affected by code smells. However, only 7% bugs,” in Proc. of ESEC/FSE, 2007, pp. 55–64.
of the performed operations actually removed the code smells [7] Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue, “Simultaneous modifi-
from the affected class. Also, Saika et al. investigated the cation support based on code clone analysis,” in Proc. of APSEC, 2007,
impact of the severity of code smell on refactoring [21]. The pp. 262–269.
[8] F. Rahman, C. Bird, and P. Devanbu, “Clones: What is that smell?”
result shows that refactoring did not decrease the severity of Empirical Software Engineering, vol. 17, no. 4-5, pp. 503–530, 2012.
code smells significantly. [9] H. Sajnani, V. Saini, and C. V. Lopes, “A comparative study of bug
patterns in java cloned and non-cloned code,” in Proc. of SCAM, 2014,
V. C ONCLUDING R EMARKS AND F UTURE W ORK pp. 21–30.
[10] N. Yoshida, T. Hattori, and K. Inoue, “Finding similar defects using
In this position paper, I focused on code cloning that is one synonymous identifier retrieval,” in Proc. of IWSC, 2010, pp. 49–56.
[11] C. J. Kapser and M. W. Godfrey, ““cloning considered harmful”
of the most well-known code-level technical debt At first, I considered harmful: patterns of cloning in software,” Empirical
introduced five context instances when developers focus on Software Engineering, vol. 13, no. 6, p. 645, 2008. [Online]. Available:
code clones according to my experience of industry/university http://dx.doi.org/10.1007/s10664-008-9076-6
[12] J. L. Overbey, F. Behrang, and M. Hafiz, “A foundation for refactoring
collaboration. After that, I discussed elements of the context c with macros,” in Proc. of FSE, 2014, pp. 75–85. [Online]. Available:
model of a software maintenance project and the impact of http://doi.acm.org/10.1145/2635868.2635908
those elements on technical debt. Based on the discussion, [13] E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner, “Do
code clones matter?” in Proc. of ICSE, 2009, pp. 485–495. [Online].
my position statement is that researchers have to identify the Available: http://dx.doi.org/10.1109/ICSE.2009.5070547
contexts of target projects in empirical studies of technical [14] M. Mondal, C. K. Roy, and K. A. Schneider, “A comparative
debt before they compare or discuss those studies. study on the bug-proneness of different types of code clones,”
in Proc. of ICSME, 2015, pp. 91–100. [Online]. Available:
As future work, I plan to perform a systematic review http://dx.doi.org/10.1109/ICSM.2015.7332455
of the existing empirical studies of technical debt and then [15] J. F. Islam, M. Mondal, and C. K. Roy, “Bug replication in code clones:
identify the contexts of those studies. After that, I would like An empirical study,” in Proc. of SANER, vol. 1, March 2016, pp. 68–78.
to categorize the identified contexts and then investigate the [16] Z. Li, S. Lu, S. Myagmar, and Y. Zhou, “CP-Miner: Finding Copy-Paste
and Related Bugs in Large-Scale Software Code,” IEEE Transactions on
impact of context on technical debt. Also, I would like to Software Engineering, vol. 32, no. 3, pp. 176–192, 2006.
propose a guideline for empirical research of technical debt [17] K. Hotta, Y. Sano, Y. Higo, and S. Kusumoto, “Is duplicate
based on above category and the investigation result. code more frequently modified than non-duplicate code in software
evolution?: An empirical study on open source software,” in
Proc. of IWPSE-EVOL, 2010, pp. 73–82. [Online]. Available:
ACKNOWLEDGMENT http://doi.acm.org/10.1145/1862372.1862390
[18] J. Harder and N. Göde, “Cloned code: stable code,” Journal of
I thank Dr. Leon Moonen and Prof. Tom Mens for useful Software: Evolution and Process, vol. 25, no. 10, pp. 1063–1088, 2013.
feedback on earlier versions of this paper. This work was [Online]. Available: http://dx.doi.org/10.1002/smr.1551
66
1st International Workshop on Technical Debt Analytics (TDA 2016)
[19] K. Stroggylos and D. Spinellis, “Refactoring–does it improve software Journal of Systems and Software, vol. 107, pp. 1–14, 2015.
quality?” in Proc. of WoSQ, no. 10, 2007. [21] T. Saika, E. Choi, N. Yoshida, S. Haruna, and K. Inoue, “Do developers
[20] G. Bavota, A. D. Lucia, M. D. Penta, and R. Oliveto, “An experimental focus on severe code smells?” in Proc. of PPAP, 2016, pp. 1–3.
investigation on the innate relationship between quality and refactoring,”
67