An Empirical Study on Technical Debt in a Finnish

SME
Valentina Lenarduzzi Teemu Orava Nyyti Saarimäki Kari Systä Davide Taibi
Tampere University Tampere University Tampere University Tampere University
Tampere, Finland Tampere, Finland Tampere, Finland Tampere, Finland Tampere, Finland
[email protected] [email protected] [email protected] [email protected] [email protected]

Abstract—Background. The need to release our products under immature implementation [2] than will be fixed in the future
tough time constraints has required us to take shortcuts during implementing a proper solution.
the implementation of our products and to postpone the correct Researchers have investigated different aspects of TD and
implementation, thereby accumulating Technical Debt.
Objective. In this work, we report the experience of a Finnish proposed different approaches to pay it back. However, only
SME in managing Technical Debt (TD), investigating the most few works have investigated concrete cases and identified the
common types of TD they faced in the past, their causes, and root causes of TD in companies.
their effects. In this work, we report on an empirical study we performed
Method. We set up a focus group in the case-company, involving in our case company, a Finnish SME that operates in Business-
different roles.
Results. The results showed that the most significant TD in the to-Business sector and develops web applications for manag-
company stems from disagreements with the supplier and lack of ing sales channels.
test automation. Specification and test TD are the most significant We identified cases where we postponed different activities
types of TD. Budget and time constraints were identified as the and then analyzed the reason(s) for the postponement, the
most important root causes of TD. issues generated by the postponement, and how the post-
Conclusion. TD occurs when time or budget is limited or
the amount of work are not understood properly. However, poned activities were implemented later. We also highlight
not all postponed activities generated ”debt”. Sometimes the the overhead generated by the postponement of the activities
accumulation of TD helped meet deadlines without a major themselves (the interest).
impact, while in other cases the cost for repaying the TD was The results of this work can be beneficial not only for the
much higher than the benefits. From this study, we learned scientific community but also for other companies. As other
that learning, careful estimations, and continuous improvement
could be good strategies to mitigate TD These strategies include companies can understand the reasons why our case company
iterative validation with customers, efficient communication with postponed some activities, and the issues generated by the
stakeholders, meta-cognition in estimations, and value orientation postponement, they can make more informed decisions in
in budgeting and scheduling. similar situations. The results of this work confirm that TD
Index Terms—Technical Debt, Small and Medium-Sized En- can cause significant economic losses if payback is postponed.
terprise
Also, postponing activities - even if it is beneficial in the short
term - can often be an economic disadvantage.
I. I NTRODUCTION We investigated our case company’s TD with a focus group
Companies commonly spend time to reduce the Technical involving five members of the company. Our main goal was
Debt (TD) in their systems. Many factors can lead to TD; they not to regret past losses, but to understand what happened in
can be internal, related to the business or the environment, or the past and find ways to prevent similar situations.
they can be external to the company [1]. The remainder of this paper is structured as follows. Sec-
TD is a metaphor from the economic domain that ”refers tion II reports on related work. In Section III, we introduce
to different software maintenance activities that are postponed the empirical study design and report the results in Section IV.
in favor of the development of new features in order to get The discussion is presented in Section V and conclusions are
short-term payoff” [2]. drawn in Section VI.
Technical issues include any kind of information that can be II. R ELATED W ORK
derived from the source code and from the software process,
such as usage of specific patterns, compliance with coding There are several ways to prevent TD. For example, Fowler
or documentation conventions, architectural issues, and many suggested that software should be designed to be strangled,
others. For example, when a new feature does not fit the i.e., to be surpassed by new versions easily [3], while ac-
current architecture, the incompatibility might solved with an cording to Cunningham, utilizing the modularity of objects
allows developing flexible software [2]. However, sometimes
debt cannot be avoided and in order to avoid rising costs, the
978-1-7281-2968-6/19/$31.00 ©2019 IEEE generated debt should be paid back as soon as possible.
 According to Z. Li, TD occurs when technical shortcuts RQ2 aims to investigate the causes of the TD identified in
are taken to gain short-term benefits that are harmful for the the company.
system in the long term [4]. There are several reasons that lead RQ3 aims to identify ways to prevent TD from occurring
to technical compromises, such as unrealistic schedule, budget in the future based on the knowledge gained by RQ1.
constraints, or estimation errors. Highly indebted products
B. Planning the study
become inflexible and unprofitable, and the accumulation of
debt eventually leads to dead end whereupon the system has We planned a focus group to last from two to three hours.
to be replaced with a new one. We identified a number of issues to be covered that were
Klinger et al. [5] interviewed four software architects to sufficient for having a meaningful discussion and interaction
understand how decision-making regarding TD was conducted between the participants.
in an enterprise environment. The results showed that the We selected five participants: the Chief Technology Officer
decisions related to TD issues were often informal and ad-hoc, (CTO), the Chief Financial Officer (CFO), the Chief Marketing
which prevented tracking and quantifying the decisions and Officer (CMO), and two developers. All participants voluntar-
issues. Moreover, just as in our work, this study also reported ily participated in the study, as they were interested in how
that there was a large communication gap between technical to avoid facing similar situations as in the past and wanted to
and business stakeholders in the discussions related to TD. understand which activities should not be postponed.
Ampatzoglou et al. [6] conducted a multiple case study The session was moderated by one of the authors, that did
in the embedded systems industry in order to investigate not vote nor participated on the identification of TD. Before the
the expected lifetime of components affected by TD and the session, the moderator introduced the goals and the rules of the
most frequently occurring types of TD. They considered seven focus group. Then he presented the following six discussion
embedded systems industries from five different countries. topics:
The results showed that in order to increase the expected T1: Which activities have been postponed in the past?
lifetime of components, maintainability plays a major role. This topic was investigated in two steps: First, the par-
Moreover, they found the most frequent types of TD to be ticipants answered this question individually, reporting
test, architecture, and code. the activities on post-it notes. Then the moderator asked
Recently, De Toledo et al. [7] conducted an exploratory case them to read their list of activities and grouped the same
study with a large company on a project with about 1,000 activities on the whiteboard.
services. They investigated Architecture TD in the commu- T2: Which type of TD was generated by the postponed
nication layer. The study combined an analysis of existing activities?
documentation and interviews to identify issues, solutions, and The participants grouped the postponed activities based
risks, providing a list of architectural issues that generate TD. on the type of TD. We adopted a classification of eleven
categories, including the ten TD categories proposed by
III. F OCUS G ROUP Li et al. [4] (Requirement TD, Architectural TD, Design
In this section, we describe the design of our study, includ- TD, Code TD, Test TD, Build TD, Documentation TD,
ing the goal, the research questions, the study context and Infrastructure TD, Versioning TD, Defect TD) and one
procedure, and the data analysis. new category (Organizational TD).
The case product was a sales channel management tool that T3: What were the reasons for postponement?
the case company offers as a service (Saas). The company Regarding this topic, the participants discussed the mo-
is a micro-enterprise (less than 10 person), that develop a tivations for the postponement of the activities and then
single product (the sales management tool). The product is reported them on the activity post-it notes created in T1.
customized for suppliers, providing a limited set of features, T4: How were the activities then implemented? In this task,
depending on their needs. the participants reported the solutions adopted to imple-
The product has been developed for 4 years (from January ment the postponed activities and reported them on the
2015) and it is based on JavaScript and NoSQL and it’s devel- activity post-it notes.
oped with the MEAN stack (MongoDB, Express.js, AngularJS T5: What problems did the postponement cause?
and Node.js). The participants collaboratively discussed the problems
that caused the postponement, including economic, tech-
A. Research Questions nical, and organizational ones. In this case as well, they
reported them on the activity post-it notes.
Based on the aforementioned goal, we derived the following
T6: Ranking the importance of the problems.
Research Questions (RQs):
In this task, each participant received ten votes, in the
• RQ1: What are the most common types of TD? form of adhesive ”dots”, and was asked to vote on the
• RQ2: What are the main causes of the accumulated TD? most harmful problems. The participants were free to
• RQ3: How to mitigate TD? distribute their votes as they liked, for example, assigning
RQ1 aims to determine the most common types of TD in all ten votes only to one activity or distributing them
the company and their impact on business. evenly among the activities.
 Except for Topic 1, if needed, participants were allowed to concentrate on fast delivery to the client. The recognized
use extra post-it notes connected to the same activity. cause were Time constraints.
TD6 Testing is expensive. (Test TD) The company lacked
C. Data Analysis dedicated tested and had human resourcing challenges.
The data collected from the focus group was analyzed by The focus group was not able to find the actual cause of
determining the proportion of responses in each category. TD this TD.
causes were analyzed following the 5-Whys technique [8]. TD7 Low code coverage in tests causes risks in development
and additional work. (Test TD) It was hard to estimate
IV. R ESULT budget and schedule in the beginning and the company
In this section, we will first report the perceived TD issues had to postpone some testing. Also, the company did not
highlighted by the participants, together with the problems the have dedicated personnel for testing, and developers were
issues generated and their causes. Finally, we will answer our not as efficient in testing as dedicated tester would be.
research questions. The recognized causes were Estimation issues, Commu-
nication issue and Budget constraints.
A. Perceived Debt
Source Code Maturity Issues
The participants if of focus group identified 10 different TD8 Lack of code documentation. (Documentation TD) The
types of TD (TD items). case company was commonly too busy to create code
Organizational and Product Management Issues documentation as new features has usually highest prior-
TD1 Implementation of multiple versions of the same product, ities. The recognized cause was Time constraints.
as different customers wanted to use the system for dif- TD9 Technical shortcuts (Code TD) These TD items are
ferent purposes. (Requirements TD, Organizational TD) present due to lacking time and budget. The recognized
The prioritization of the features and tasks as well as the causes were Time constraints and Budget constraints.
estimation of the cost and other effects of the customer- TD10 Duplicated code (Code TD) Developers failed to follow
specific tailoring became difficult. The recognized causes the ”Don’t Repeat Yourself” principle and modularize
where Specification issues, Budget constraints, Estima- the implementations. Instead they duplicated the code
tion issues and Time constraints (e.g. related to Fast because they were in hurry. In some case, the company
Delivery). had no time to extend or generalize the existing code.
TD2 Disagreement with supplier about the Minimum Viable The focus group was not able to find the actual cause of
Product (MVP) [9]. (Requirements TD) The first version this TD.
of the system was subcontracted from an external vendor
that wanted to implement the initially agreed specification RQ1. What are the most common types of TD?
instead of iterative development and adapting to improved The focus group considered the Test and Requirements TD
understanding of the customer needs. The recognized as clearly more significant than other types of TD, as reported
causes where Specification issues, Budget constraints and in Table I (b).
Estimation issues.
RQ2. What are the main causes of the accumulated TD?
Architectural Issues
The causes of the perceived TD items are summarized in
TD3 Lack of multitenancy causes budgeting increase and Table I (c).
lack of flexibility (Infrastructure TD). The products are
1) Budget constraints (TD1, TD2, TD3, TD7, TD9) and time
delivered as SaaS services, but the implementation forces
constraints (TD1, TD4, TD5, TD8, TD9) are the most
a totally separated installation for each customer. This
recurring reasons. Estimation issues (TD1, TD2, TD7) is
raises the operation and infrastructure costs. Multitenancy
also a significant cause and closely related to budgeting
was not originally the highest priority and then the need
and timing.
of introducing it is costly. The recognized cause was
2) Time-related causes (Time constraints), usually related
Budget constraints.
to fast delivery, recurred almost as frequently as budget
TD4 Hard to maintain a simple User eXperience (UX) with
constraints. It can be speculated that the lack of time
the growth of functionalities. (Design TD) The UX was
depends on the budget.
designed by the supplier that did not want to redesign it
3) Other causes were not as significant.
anymore, creating issues in adding new features while
4) In some cases, the causes of the TD remain unknown.
maintaining a good user experience. The recognized
cause was Time constraints. RQ3. How to mitigate TD?
Development and Testing issues Based on the discussion of the focus group we highlighted
TD5 Lack of automatic testing costs more in the future (Infras- three main aspects that could be improved to mitigate TD.
tructure TD). The testing budget was too low to enable 1) Learning from customers. Organizations have to under-
the creation of automatic testing during development stand what should be built using prototypes and validation
since the company did not even have enough time to with customers.
 (a) Perceived by interviewees and total points (b) perceived TD types and sum of point (c) Count of TD motivations presented
TD Type Points Possible cause of motivations Count
TD Description Points Test TD 11 Budget constraints 5
TD2. Disagreement with supplier 7 Requirements TD 10 Time constraints 5
TD5. Lack of automatic testing 7 Code TD 5 Estimation issues 3
TD1. Implementing multiple products 3 Organizational TD 3 Specification issues 2
TD0. Technical shortcuts 3 Infrastructure TD 2 Communication issues 1
TD6. Expensive tests 2 Documentation TD 2 Design issues 1
TD3. Lack of multitenancy 2 Design TD 0
TD8. Lack of code documentation 2 Architectural TD 0
TD7. Low code coverage in tests 2 Build TD 0
TD10. Duplicate code 2 Versioning TD 0
TD4. Hard to maintain simple UX 0 Defect TD 0
Grand Total 30

TABLE I: Results. Motivations are counted once for each TD

2) Careful estimation. The whole organization should under- team reaches its optimal performance in group development,
stand the technical boundaries to avoid estimation errors. as reported by B. Tuckmann [11].
They should use previous tasks to improve their effort When discussing the lack of documentation, the CTO said,
estimation regarding the development of new tasks. Un- ”We faced this TD about not having the documentation when
derestimation can cause additional expenses for company. you [developer] came and we did these bug fixes during the
Customers should pay for the overall costs of the system; autumn. Had there been these, I think it would have been a
they tend to pay only for visible costs, which are only the little bit easier.”
tip of the iceberg. The costs of testing and documentation,
which tend to be under the surface, should be made
visible to them. The company has to find the right pricing
A. Learning from Customer
balance in order to remain competitive. Underestimating
the amount of work can lead to compromises in less Learning from the customers is the first answer to RQ3
visible costs. regarding how to mitigate TD. As stated by one developer,
3) Continuous improvement. Organizations can gradually when the organization knows the customer’s needs, it it is
improve the quality. Deficiencies in development areas easier to go in the right direction. When there are many
should not be postponed. Companies should invest in customers, User Experience Design becomes more important
testing and documentation because their TDs are hin- as a generalized solution has to satisfy everyone’s needs at the
dering development and ultimately take up a lot of the same time. ”We are kind of having it done by experimenting
developers’ precious time. A lack of tests increases the and communicating more with the customers to understand
need for manual testing and the risk of regression. Lack what they need and we are doing it in an iterative way to
of documentation diminishes knowledge and adds tacit solve the customer’s problem, but this works until we have
knowledge. Evanescence of knowledge will accumulate only handful of customers.”
the costs of testing and documenting over time. Compa-
nies have to find the critical point in mitigating TD where Idea validation with users using prototyping could follow
benefit is bigger than cost. validated learning as suggested by E. Ries [12]. According to
M. Christel et al. [13], the customer has to be supported in
V. D ISCUSSION requirements elicitation because the customer’s understanding
Identifying TD and its possible root causes helped the is limited. However, the CTO stated that the customer should
company to understand their most critical issues. Conversation be consulted only for major decisions and should not be
helped to determine the causes of accrued TD to enable miti- bothered with every minor detail.
gating TD in the future. Ways to mitigate TD were explored Problems caused by a lack of validation were emphasized
based on the results. Budget constraints were considered as when the subject company outsourced their software devel-
the most critical root cause of TD; however, time constraints opment. Sections that are more important for the business
and fast delivery were considered almost as critical. than strategically can be outsourced. Outsourcing can allow
Time constraints can be related to budget constraints when companies to focus on their core competence, but suppliers
they are caused by HR constraints. However, they do not al- have their own interests and all the decisions have to be well-
ways relate to budget as more employees do not automatically reasoned. The CFO stated ”that was why we were so upset with
remove time constraints. According to FP. Brooks [10], work them [the Supplier] because the plan was to have something
distribution follows Amdahl’s law. Thus, the more work is not so solid in the back end but we could have a couple of
distributable, the more time is saved by adding developers. The customers to actually test. Problem is that they chose not to
required learning curve and the need for more communication give us that; we had to wait two years before we were able
lessen the benefit of having more employees. Thus, even if to have a customer to test the MVP and that was their big
the budget is sufficient, time constraints can remain until the mistake.”
B. Careful Estimation was quite a big change and they said that ’no, we won’t pay
that much’ and then we said we cannot do it. They were not
Careful estimation is the second answer to RQ3. SMEs need very happy but we had no choice. It was too expensive and
to use their budget wisely. A limited budget forces a company the client did not see any value in that.”
to generate TD which it hopes to pay back as soon as possible. Careful estimation avoids risks. In addition to commu-
Payback time can be when the company gets enough funding. nication issues, estimation errors can be reasons that drain
The risk of a roadblock through a ”TD bankruptcy” increases the budget. As mentioned in the Results, underestimation is
when new requirements emerge and need attention, leading unprofitable for the company. Estimation errors occur because
to the rewriting of existing features, which should be avoided of unpredictable complexity of a task. Developers might not
by estimating the costs of TD. Moreover, outsourcing part see all the sub-tasks concerning a new task when doing the
of the development to consultants, also increase the risk of estimation at the beginning of the development of a new task.
requirement TD [14] related to misunderstandings [15] and Every new task is unique and has little in common with
increase the communication overhead [16]. the previous tasks. A little knowledge of the subject makes
For an SME, budget constraints are inevitable and the developers overconfident, which leads to them underestimating
company needs ways to cope with its budget. Considering the the amount of work. Again, only the tip of the iceberg is seen
lifecycle of companies, Nilsson et al. [17] claimed that in the and a new task is seen as simpler than it actually is in the end.
pre-deployment phase, architectural and structural TD should When pricing and schedule are unrealistic, development will
be avoided. Other types of TD such as test and documentation focus only on the most critical areas. Pessimism in estimation
TD can be incurred in that phase. Communication is important could help to improve quality, but the challenge is to maintain
especially at the beginning in order to avoid wrong decisions competitiveness with bigger companies that have economies
that later become TD. Any historical analysis of budget of scale and can use their capital to fund all the various
constraints is speculative and thus no single reason can be aspects. Companies can find estimation challenging, as stated
named. Inadequacy in in specification validation can drain by the CFO: ”The client paid us like 10,000 euros for the
the budget. TD2, disagreement with the supplier, was one of customization and between our hours and what we paid to
the most important TD items. The CFO stated that concrete do that modification it costed us 15,000-17,000 euros. We
prototypes could have helped validation. Lack of prototyping accepted the specification but we totally did not understand
consumed time and caused bitterness. Decisions made were how much it would actually cost and how much time it would
not optimal in the long term and caused TD. take because it was done in a rush.”
Planning requires good communication. Stakeholders Companies can improve in finding critical point in estimates
should make sure they consider every aspect of new features, by time meanwhile preparing for estimation errors. As stated
utilizing, for example, the Architecture Trade-off Analysis by C. Parkinson [20], his namesake law leads to overestimation
Method (ATAM) to find possible trade-offs in architecture since after some point, finishing a task requires the same time
decisions by formally listening to all stakeholders [18]. A regardless of the allocated time. Meanwhile, according to D.
customer approaches the product from a top-down perspective. Hofstadter [21], his namesake law leads to underestimation
They cannot see all the technical details related to the imple- since a task requires more time than estimated although the
mentation of a feature. On the other hand, developers are able estimator would be aware of estimation challenges.
to see the bottom-up perspective and know all the technical
aspects quite well. However, they might have deficiencies in C. Continuous Improvement
domain knowledge and cannot value all the customer’s needs. Continuous improvement is the third answer to RQ3. Ac-
Both parties become victims of the Dunning-Kruger effect [19] cording to a developer, the quality of the code has suffered
when they fail to look below the surface. from a lack of unit tests. Testing is needed to validate
When discussing the implementation of features for multiple conformance. One developer stated: ”Requirements were not
products, the CFO said ”I don’t think they [the Supplier] written anywhere and if you touch and you happen to break
took really that much time to understand because in every something it’s even hard to regulate what’s broken until it gets
meeting we repeated the same. It was very important and in the into the customer’s hands.”
specification, the written specification, and even in the contract Companies need to find the golden mean in quality improve-
they signed, this was written.” The supplier’s developer for his ment, where the cost-benefit ratio is the lowest [22]. Moreover,
part commented ”the Client’s team was not able to convince companies should consider continuous quality monitoring ap-
us of that and explain the idea really well. The reason is the proaches, instead of one-shot refactoring [23] [24].
domain knowledge, the deficiency on the Supplier’s side.” Testing, documenting, and bug fixing are ways to reduce
Just as with suppliers, companies face challenges in justi- waste in software development. Testing and fixing bugs be-
fying the work to be done with customers. The customers do come more difficult over time when software entropy in-
not see the less visible costs, which should be communicated creases. According to the CFO, “at the latest stage when we
to them as they improve the long-term health of the system. are going to do the automated testing, which is very important
The CFO gave the following example: ”We had an issue that anyway, it’s going to cost us quite a lot because we need to dig
one of our customers wanted to modify the questions. [...] It into the old code of the application so we need to go back.“
 VI. C ONCLUSION R EFERENCES
In this work, we analyzed the main reasons for Technical [1] A. Martini, J. Bosch, and M. Chaudron, “Investigating architectural
technical debt accumulation and refactoring over time: A multiple-case
Debt (TD) in an SME company, the problems it created, and study,” Information and Software Technology, pp. 237 – 253, 2015.
how the company mitigated it. We investigated what happened [2] W. Cunningham, “The wycash portfolio management system,” SIGPLAN
in the past, so as to avoid making the same mistakes again, OOPS Messenger, vol. 4, no. 2, pp. 29–30, 1993.
[3] M. Fowler, “Stranglerapplication,” 2004. [Online]. Available:
or to make reasoned choices. Our participants considered the https://www.martinfowler.com/bliki/StranglerApplication.html.
most significant TD items to be disagreement with suppliers [4] Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on
and lack of test automation. The most significant TD types technical debt and its management,” Journal of Systems and Software,
vol. 101, pp. 193–220, 2015.
were Test and Requirements. Possible root causes were budget [5] T. Klinger, P. Tarr, P. Wagstrom, and C. Williams, “An enterprise
constraints, estimation and specification issues, and fast deliv- perspective on technical debt,” in MTD ’11, 2011, pp. 35–38.
ery. Overall, the most important root causes were considered to [6] A. Ampatzoglou, A. Ampatzoglou, A. Chatzigeorgiou, P. Avgeriou,
P. Abrahamsson, A. Martini, U. Zdun, and K. Systa, “The perception
be budget constraints, time constraints, and estimation issues. of technical debt in the embedded systems domain: An industrial case
Attempting to build a connection to management theory study,” in MTD ’16, Oct 2016, pp. 9–16.
helps to understand the issue of TD in depth. Based on the [7] S. De Toledo, A. Martini, A. Przybyszewska, and D. Sjoberg, “Architec-
tural technical debt in microservices. a case study in a large company,”
analysis of the results and related work, the following methods in TechDebt 2019, 2019.
can be used to mitigate TD: [8] T. Ohno, Toyota production system: beyond large-scale production. crc
Press, 1988.
• Learning from customers - prototyping with the cus- [9] V. Lenarduzzi and D. Taibi, “MVP explained: A systematic mapping
tomers to find the right direction and communicating study on the definitions of minimal viable product,” in Euromicro
efficiently with the stakeholders; Conference on Software Engineering and Advanced Applications, 2016.
[10] F. P. Brooks Jr, “The mythical man-month (anniversary ed.),” 1995.
• Careful estimation - using meta-cognition to learn esti- [11] B. W. Tuckman, “Developmental sequence in small groups.” Psycholog-
mation; ical bulletin, vol. 63, no. 6, p. 384, 1965.
• Continuous improvement - using limited budget and time [12] E. Ries, The lean startup. Crown Books, 2011.
[13] M. G. Christel and K. C. Kang, “Issues in requirements elicitation,”
wisely to bring value. Carnegie-Mellon Software Engineering Inst, Tech. Rep., 1992.
Another result is that requirements were not validated [14] V. Lenarduzzi and D. Fucci, “Towards a holistic definition of require-
ments debt,” in 13th International Symposium on Empirical Software
properly at the beginning when a product was outsourced to Engineering and Measurement, Sept 2019.
an external supplier. Moreover, the developers underestimated [15] D. Taibi, V. Lenarduzzi, A. Janes, K. Liukkunen, and M. O. Ahmad,
the time for testing and bug fixing. As estimation errors are “Comparing requirements decomposition within the scrum, scrum with
kanban, xp, and banana development processes,” in Agile Processes in
harmful to budgeting and scheduling, awareness of one’s own Software Engineering and Extreme Programming, 2017.
competence and transparency in communication can avoid [16] D. Taibi, V. Lenarduzzi, M. O. Ahmad, and K. Liukkunen, “Comparing
risks in the future. communication effort within the scrum, scrum with kanban, xp, and
banana development processes,” in 21st International Conference on
This work provides an overview of the main issues related to Evaluation and Assessment in Software Engineering, ser. EASE’17,
TD in our case company. However, we are aware of different 2017.
threats that may have influenced the results. Some participants [17] H. Nilsson and L. Petersson, “How to manage technical debt in a lean
startup,” 2013.
might not have reported some TD issues for different reasons. [18] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, and J. Car-
The presence of the company’s technical management (CTO, riere, “The architecture tradeoff analysis method,” in Inter. Conference
CFO, and CMO) could have influenced the answers of the on Eng. of Complex Computer Systems, 1998, pp. 68–78.
[19] J. Kruger and D. Dunning, “Unskilled and unaware of it: how diffi-
developers. The focus group was conducted over a period of culties in recognizing one’s own incompetence lead to inflated self-
two hours, and therefore we probably have not reported all assessments.” J. of personality and social psych., vol. 77, no. 6, 1999.
the issues that occurred during the history of the company, [20] C. N. Parkinson and R. C. Osborn, Parkinson’s law, and other studies
in administration. Houghton Mifflin Boston, 1957, vol. 24.
but only the most recent or the most significant ones. [21] D. R. Hofstadter et al., Gödel, Escher, Bach: an eternal golden braid.
Further studies are needed to create a stronger bond between Basic books New York, 1979, vol. 20.
the effects of validation and estimation on the one hand and [22] S. H. Vathsavayi and K. Systä, “Technical debt management with genetic
algorithms,” in Euromicro SEAA, 2016.
budgeting and scheduling on the other hand. Benchmarks of [23] V. Lenarduzzi, C. Stan, D. Taibi, D. Tosi, and G. Venters, “A dynamical
our estimations with existing dataset [25] and adopting TD quality model to continuously monitor software maintenance,” in 11th
management tools widely used by competitors [26] [27] could European Conference on Information Systems Management, 2017.
[24] A. Janes, V. Lenarduzzi, and A. C. Stan, “A continuous software quality
be a viable solutions to mitigate this threat. Understanding monitoring approach for small and medium enterprises,” in International
these laws also requires interdisciplinary studies that combine Conference on Performance Engineering Companion, 2017.
computing, quality management, and psychology. A contin- [25] V. Lenarduzzi, , N. Saarimäki, and D. Taibi, “The technical debt dataset,”
in Int. Conf. on Predictive Models and Data Analytics in software
uous quality management approach [24] [23], could help to engineering (PROMISE’19), Sept 2019.
prevent TD. Moreover, management studies help to develop [26] V. Lenarduzzi, A. Sillitti, and D. Taibi, “A survey on code analysis
better processes, while psychology and organizational studies tools for software maintenance prediction,” in Software Engineering for
Defence Applications - SEDA, 2019.
can explain why estimation errors occur. Understanding root [27] V. Lenarduzzi., A. Sillitti, and D. Taibi, “Analyzing forty years of
causes by looking at them through these fields will result in software maintenance models,” in International Conference on Software
better knowledge of TD and help SMEs avoid pitfalls, thereby Engineering Companion (ICSE-C), 2017.
enabling them to be even more successful.