ion of the channel patterns into rules is pursued so that development tools may automatically maintain technical debt information with them (the authors have introduced the DebtFlag tool for this). Hence, successfully implementing this study would allow further understanding and describing technical debt propagation at both the high level (longitudinal technical debt propagation e ects for the project) and the low level (artifact level e ects describing the mechanism of technical debt value accumulation).
Technical debt is a software development concept that is interested in exposing
asset management characteristics for project trade-o s [
It has been argued [
Technical debt research has been pro cient in suggesting identi cation,
tracking, and governance solutions to overcome the technical debt information
production issues [
Today, the software projects that plug into social media services through APIs (Application Programming Interface) are an exemplar eld of software context versatility. Updates to these APIs, invoked by their external authors, indicate sources of technical debt accumulation and propagation in their clients', often business critical, software. Mining Software Repositories (MSR) for the clients that are subject to these updates enables studying the software context space to address the cap in technical debt propagation knowledge.
In the 1980s software applications were relatively simple and they were
delivered as is. They were relatively bug free and needed no updates. Once an
application was released, any existing technical debt was outside the organization's
control. As software grew increasingly complex, especially with the emergence
of the Internet in the 1990s, bigger applications were released with more issues
remaining. The practise eventually turned out having regularly released patches
as a norm, as they were also easily distributed through the net. Technical debt
was feasible and also realized. Now, in the 2010s we have complex applications
that not only utilize third party libraries, but also third party services through
APIs. There are regular updates to the libraries and the APIs, as well as to the
client applications themselves. These all are sources of technical debt. Further, as
previously shown [
Our intention is to understand the technical debt propagation context by investigating the latest trends: use of external APIs and especially those of social media services. The paper is structured as follows: we begin in Section 2 by reviewing the background. Section 3 builds on this and introduces our technical debt propagation research objectives. We introduce our approach to overcome the objectives and initial results in Section 4. The concluding remarks appear in Section 6. 2
We will introduce here related work regarding technical debt, propagation in the software context, and APIs. Whilst de ning core concepts for the article's foundation, empirical work is also visited so as to further understand the state of current research. 2.1
The term \technical debt" was initially coined by Ward Cunningham [
Firstly, McConnell [
Management of technical debt requires that we are capable of identifying and tracking the trade-o s, the atomic instances, that form the debt for a project.
Without this information readily available, trained decision regarding the debt's
governance cannot be made [
From the latest systematic mapping study on technical debt [
Lastly, we note that technical debt tracking is the process of indicating
technical debt propagation in the software context. To this end, the authors identify
only the work by McGregor et al. [
What is pursued herein is a better understanding of the context of technical debt
propagation in software. We argue that software change should be considered the
fundamental unit for this. Something that Schmid [
Kagdi et al. [
In this work, the mining e orts focus on large open-source,
social-networkingenabled, repositories in order to maximally cover the diversity of software change.
Tsay et al. [
In the following we address our ongoing technical debt propagation research on two distinct levels: the inter-dependency e ects at the software artifact level and the longitudinal e ects at the project level. 3.1
As discussed in Section 2, a multitude of solutions exist for both identifying and tracking technical debt. However, most of the solutions are intended for pre-de ned software development contexts; for example, limiting their use to a speci c sub-set of implementation techniques and herein, during continued software development, to certain mechanisms for technical debt propagation.
However, the ability to produce exhaustive technical debt information
requires that all possibilities for technical debt propagation are acknowledged. We
postulate, based on the properties of technical debt identi ed by Brown et al. [
Foremost research area for technical debt propagation in software artifacts, is (1) to show that technical debt propagates between software components that can exist in external and independent projects and be implemented using di erent technologies. The interest and even the whole initial debt can be created in an external, but linked project that is worked by another team. The works referred here do not dispute this information, and may even implicitly assume this, but it is important to recognize this phenomenon explicitly and have quantitative research conducted on it to indisputably point it out.
Second research area, partially reliant on the rst, is (2) to accumulate a documentation that describes the possible ways in which technical debt can propagate. Preferably, this would be a taxonomy capturing the unique propagation channels for technical debt. Finally, in order to enable information delivery for technical debt management purposes, (3) the channel descriptions must be enriched with information regarding technical debt value accumulation for all unique accounts of propagation. This would enable, possibly automated, technical debt information maintenance as the taxonomy is capable of tracking and valuating technical debt through out the software project. One way to identify the propagation of technical debt is to make longitudinal studies of increased debt in di erent phases of a project and connect them with the root causes. Technical debt can be identi ed as matters, such as discovered vulnerabilities, updates, and feature discontinuation in systems related to the project. Also, adding a new feature in a utilized external service API may cause technical debt when the project customer wants the new feature implemented in the project. We can identify di erent propagation paths by following how such an event causes extra work in the chain of projects (COP) that are all linked with each other.
If an API is not interfaced directly but through a third party library, it may be that the customer is not happy to wait until the library is updated with the new feature. This will cause the project debt to be paid by implementing this new feature quickly with an internal solution. This will become a new kind of a debt, from the opposite end of the COP, when the referred library is nally updated. Here, the internal solution becomes legacy and requires refactorization into a solution that utilizes the library again, for example, in accordance to the coding conventions followed by the programming team.
There are cross waves moving back and forth in the COP from the root cause, through the library, to the end of chain application. These can be tracked by following the amount of increased work in each area.
Figure 1 demonstrates a sample classi cation for COPs. Here, case 1 demonstrates a monolith project that has internally implemented services with no outside dependencies. This is a classical, and probably the most studied, scenario for technical debt management, where the debt is only internally caused, felt, and managed. Cases 2 through 4 depict more modern scenarios, where the projects depend on external service providers. In case 2, the project has a direct dependency to the service and adapts explicitly and directly as invoked by the service. A slightly dampened version, but still fully managed by the project organization is presented in case 3, where the project, possibly alongside with the organization's other projects, uses an internally produced adapter to access the service. Hence, the project itself does not directly feel changes in the external service, but adaptation to them is still managed internally. Finally, in case 4 the project uses an external adapter to access the service. The external adapter generally serves a broader range of projects and hence is not customized for the needs of speci c projects. On the other hand, external adapters tend to retain compatibility as long as possible which dampens change speeds invoked by the external service.
The classi cation in Figure 1 is especially important from the viewpoint of distinguishing between the \noisy" and the technical debt inclined software changes, as the monolith projects of similar size can be used as the baseline when studying how the external service invokes and propagates technical debt. Further, as per the previous description, it can be expected that the invoked technical debt will propagate quicker in the directly dependent cases than in the indirect cases 2 to 4. 4
Exploiting open source code repositories enables us to make longitudinal surveys of the history. The GitHub code repository service 1 appears as a treasure trove for this kind of research. We can take a project from GitHub, and we can nd for it, neatly logged, each change and its date with great detail.
GitHub gives an open access to several di erent projects. However, there is also an option of hosting private projects for premium users as mentioned in Section 2.2. With only the public access to the repositories, the sample is likely to be biased. This means that traditionally non-disclosed for-pro t projects cannot be found in GitHub like this, which entails that a lot of professional work is not covered by this study. However, it can be argued that functionality is delivered via the same technologies in closed-source projects.
Furthermore, regarding mapping the software change (as discussed in Section 2), the GitHub API gives an easy access to byte-wise size of source les and line-wise size of code change per commit. Through this we have the scale of the whole project in bytes, but the scale of changes in lines of code. Optimally both variables would be measured identically, but we can only rely on these two measures being su ciently comparable. The only other option would be to go through the source les and count the line breaks outside the GitHub API support.
As elaborated in Section 3, we want to observe the propagation of technical debt on both at the software project and the software artifact levels, and with as little constrain as possible so as to capture the propagation context as complete as possible. Herein, we face the problem of how to identify technical debt in a highly diverse setting, and this is the reason why we emphasize the novelty of researching open-source social-networking-enabled projects.
Figure 2 captures the di erent technical debt accumulation classes for projects with dependencies to external services. Case 3 depicts the most common situation in which the project accumulates technical debt that realizes at a certain point in time. In case 1 factors external to the component and its development invoke technical debt, and it may realize and invoke management needs at a point in time. In case 2 technical debt has realized (its interest probability is one, or a decision to remove the debt has been made) and it a ects the project. In this scenario, the debt will propagate onwards, directly or through intermediaries, and accumulate in dependants. Accumulation channels are addressed in Figure 3.
The classi cation in Figure 2 is important for distinguishing technical debt inclined software change, as we must be able to distinguish between invoked change (case 2) and internally accumulated debt (case 1 and 3). This is because the monolith projects (see Figure 1) are able to internally accumulate technical debt, and we must form the baseline whilst aware of this.
In addition to source code, open-source projects provide access to documentation and other descriptors. Of these, the social media enabled ones form a set of projects that share a joint technical debt inducer: the social media APIs. These APIs provide business critical functionality for the projects, and every time they change, it causes several changes for their clients. Due to the massive adoption of social media services, their APIs (e.g., the Facebook Graph API 2 and the Google OpenID API 3) integrate into and a ect a vast amount of projects. This diverse collection of technologies, which all connect to the APIs that now cause changes for them, unveils a unique opportunity for technical debt research. As the changes propagate through various di erent technologies, they demonstrate a variety of technical debt propagation paths. Whilst our survey on to the social media involved open-source does not capture the full propagation space, particularly, propagation to business processes, it does yield a formidable library for the propagation of technical debt in delivered software and its supporting structures. Considering that usually this corresponds to the projects' delivered value, research should have a special interest to it.
Figure 3 demonstrates two channels, from a plethora of foreseeable options, through which technical debt can propagate and accumulate in new components. The upper channel captures a more problematic propagation method, in which no explicit dependency exists. In this, accumulated technical debt in the form of incomplete documentation causes a misunderstanding in a conceptualization phase of software development and leads to a complex component design. The lower channel demonstrates an explicit channel, where an interface change is felt in the dependent project as component disconnection. For example, a referred class is renamed in the service due to which the client can not access it in the original fashion. This leads to an erroneous implementation state in the dependent and undoubtedly invokes reparation e orts. In our MSR of open-source projects, over going both the human-produced messages and the automatically
identi ed changes should reveal instances that t both channels shown in Figure 3, but due to its implicit nature, identi cation of cases in the upper channel will be di cult. 4.1
We use the GitHub API through PyGithub/PyGithub library 4. Our crawler is a Python program 5 designed to crawl through all commits of a given project and report, for each commit, the date it was committed, the amount of changes (as the amount of added and removed rows), and the changed les. As such, our crawler is in itself an end part of a COP.
For an initial test of concept we chose Google's closing of OpenID 2.0 service
on April 20th 2015 [
Our analysis produced the graphs shown in Figure 4.The blue colour is used for sails-auth, red for festivals and cyan for waterlock. The X-axis marks the time. The dots denote the amount of changes in a commit. The bars denote commits 4 see https://github.com/PyGithub/PyGithub and in similar fashion for the other mentioned repositories as well 5 GitHub repository tomibgt/GitHubResearchDataMiner 4 10 3 10 2 10 1 10 4 10 3 10 2 10 0 10 Oct 2014
Nov 2014
Dec 2014
Jan 2015
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015 0 10 Oct 2014
Nov 2014
Dec 2014
Jan 2015
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015 ) e 5 im01 T 2 l , a 0 v 2 o e M R ( e M R ( 0 10 Oct 2014
Nov 2014
Dec 2014
Jan 2015
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015 for a time period at least a week long. The lines denote commit frequency for previous time interval of at least a week. Finally, on the graph is marked the date-of-interest, April 20th 2015.
The lines show a general decline, which would appear to indicate that as a project progresses, less and less changes are made for it. Note that the Y-axis is logarithmic, which makes the lines curve down, instead of appearing linear.
It would appear to be supporting our hypothesis, where, after the marked date, sails-auth and festivals show decrease in the decline, unlike the control project waterlock. With only three projects and without more precise investigation we can not, of course, claim this to be strong evidence, but it is enough to encourage us in continuing with this approach.
With moderate work, the analyser can be modi ed to point out the les where there has been increasing changes in the commits correlating to the investigated events. (See Tables 1 and 2.) Looking into the changes made into these les should help us to analyse further the e ort put by the programmers to pay the speci c technical debt. Also, it should be possible to follow the wave of changes throughout the COP and analyse the propagation of the debt and the involved work and communication. 5
The aforedescribed approach is limited by certain factors which we would like to address here. Firstly, we described this method as a possibility to explore the complete software context space, but the study design suggests using service calls to, especially social media, APIs and libraries as the method. It can be assumed, as previously discussed, that this approach does not capture all possible varieties of software change (see 2.2). This is a foreseeable data limitation even though it can be argued that the volume of captured changes would produce a representative set for analysis; accumulating enough assurance to allow abstraction to non-captured context areas.
Second, there are limitations potentially a ecting the identi cation of technical debt instances. We discussed the technical debt properties which can be used to associate a software change with managing technical debt. While this set of properties currently accounts the state-of-the-art from technical debt research, if not exhaustive, the properties may lead to missing particular sub-classes of technical debt. Approach discussed in the following paragraph, can be considered a partial remedy to this.
Finally, foreseeable limitations may also a ect the tracking of technical debt
instances. As a premise for tracking, [
Overcoming the limitations and achieving the study's objectives, there is a number of applications for the results (discussed in Section 3.1). Firstly, demonstrating technical debt's ability to propagate, almost boundlessly, between software projects and artifacts should fuel the apparent paradigm shift in software life-cycle management where the inter-connectivity of software project entities carries increased value. Second, documenting the ways in which technical debt can propagate should provide an interface for integrating knowledge from other research domains to enhance technical debt management by for example applying nancial models for technical debt strategization. Lastly, associating the documentation's technical debt propagation channels with information regarding their value accumulation allows automated tooling approaches to be introduced, but also makes technical debt an integral and explicit component of the software project's value production and its assessment. 6
With similar studies in the future, using di erent event markers, it is possible to map the propagation of technical debt by observing the amount of increased work caused by di erent causes of technical debt. It is possible to observe who pays the technical debt and how it is propagated from the original cause (e.g., a change in a fundamental library used by many projects) through facade libraries and components to the nal applications.
In an e ort to e ciently analyse the propagation of technical debt through
propagation channels, a taxonomy of projects in GitHub should be created to
help characterize and predict the characteristics of the projects. To this end,
and to achieve the goals stated herein, we have analyzed over twenty-eight
thousand projects from GitHub and have successfully identi ed a number of projects
with references to suitable external services. According to Lambe [
There can, of course, be other causes to variance within a class. For example,
it would be bene cial to have the information of the process maturity level for
each project team. This kind of information would be signi cant in
understanding the project's sensitivity to external changes and the general preparedness
and carefulness in the design. [
Such work would provide us with a better understanding of the economy of technical debt, which again would help us give good estimates on the actual costs of applying, for example, social media APIs in an application system and compare it with the projected bene ts and income. It would help in answering the question: would applying certain features increase the revenue from the service.
J. Holvitie is supported by the Nokia Foundation Scholarship and the Finnish Foundation for Technology Promotion, the Ulla Tuominen Foundation, and the Finnish Science Foundation for Economics and Technology grants.