Factors affecting Technical Debt Raw data from a systematic literature map

"This document presents the complete list of references that have been short listed during the systematic review process carried out during the months of April-September 2012. The objective of the systematic review was to identify current research trends in technical debt and to explore the relationship between technical debt measures and agile software development. This documents includes 352 references that are categorized according to their relevance to technical debt research." [Abstract

Offerings That are ‘‘Ever-in-the-Making’’

Digital ventures are entrepreneurial young firms that introduce new digital artifacts that are “ever-incomplete” and “perpetually-in-the-making” onto the market. The study examines how six digital ventures continued to develop their digital market offerings post launch. Three key designing mechanisms are identified that explain continuous post-launch product development in digital ventures: deploying complementary digital objects, architectural amplification, and porting. The study discusses how these mechanisms advance our understanding of how digital technologies change entrepreneurial processes and outcomes

Technical Debt: An empirical investigation of its harmfulness and on management strategies in industry

Background: In order to survive in today\u27s fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process.Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today’s software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives.Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity.Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer’s working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD.Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial\ua0effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD

Facing the Giant: a Grounded Theory Study of Decision-Making in Microservices Migrations

Background: Microservices migrations are challenging and expensive projects with many decisions that need to be made in a multitude of dimensions. Existing research tends to focus on technical issues and decisions (e.g., how to split services). Equally important organizational or business issues and their relations with technical aspects often remain out of scope or on a high level of abstraction. Aims: In this study, we aim to holistically chart the decision-making that happens on all dimensions of a migration project towards microservices (including, but not limited to, the technical dimension). Method: We investigate 16 different migration cases in a grounded theory interview study, with 19 participants that recently migrated towards microservices. This study strongly focuses on the human aspects of a migration, through stakeholders and their decisions. Results: We identify 3 decision-making processes consisting of 22decision-points and their alternative options. The decision-points are related to creating stakeholder engagement and assessing feasibility, technical implementation, and organizational restructuring. Conclusions: Our study provides an initial theory of decision-making in migrations to microservices. It also outfits practitioners with a roadmap of which decisions they should be prepared to make and at which point in the migration.Comment: 11 pages, 7 figure

Cloud provider independence using DevOps methodologies with Infrastructure-as-Code

On choosing cloud computing infrastructure for IT needs there is a risk of becoming dependent and locked-in on a specific cloud provider from which it becomes difficult to switch should an entity decide to move all of the infrastructure resources into a different provider. There’s widespread information available on how to migrate existing infrastructure to the cloud notwithstanding common cloud solutions and providers don't have any clear path or framework for supporting their tenants to migrate off the cloud into another provider or cloud infrastructure with similar service levels should they decide to do so. Under these circumstances it becomes difficult to switch from cloud provider not just because of the technical complexity of recreating the entire infrastructure from scratch and moving related data but also because of the cost it may involve. One possible solution is to evaluate the use of Infrastructure-as-Code languages for defining infrastructure (“Infrastructure-as-Code”) combined with DevOps methodologies and technologies to create a mechanism that helps streamline the migration process between different cloud infrastructure especially if taken into account from the beginning of a project. A well-structured DevOps methodology combined with Infrastructure-as-Code may allow a more integrated control on cloud resources as those can be defined and controlled with specific languages and be submitted to automation processes. Such definitions must take into account what is currently available to support those operations under the chosen cloud infrastructure APIs, always seeking to guarantee the tenant an higher degree of control over its infrastructure and higher level of preparation of the necessary steps for the recreation or migration of such infrastructure should the need arise, somehow integrating cloud resources as part of a development model. The objective of this dissertation is to create a conceptual reference framework that can identify different forms for migration of IT infrastructure while always contemplating a higher provider independence by resorting to such mechanisms, as well as identify possible constraints or obstacles under this approach. Such a framework can be referenced from the beginning of a development project if foreseeable changes in infrastructure or provider are a possibility in the future, taking into account what the API’s provide in order to make such transitions easier.Ao optar-se por infraestruturas de computação em nuvem para soluções de TI existe um risco associado de se ficar dependente de um fornecedor de serviço específico, do qual se torna difícil mudar caso se decida posteriormente movimentar toda essa infraestrutura para um outro fornecedor. Encontra-se disponível extensa documentação sobre como migrar infraestrutura já  existente para modelos de computação em nuvem, de qualquer modo as soluções e os fornecedores de serviço não dispõem de formas ou metodologias claras que suportem os seus clientes em migrações para fora da nuvem, seja para outro fornecedor ou infraestrutura com semelhantes tipos de serviço, caso assim o desejem. Nestas circunstâncias torna-se difícil mudar de fornecedor de serviço não apenas pela complexidade técnica associada à criação de toda a infraestrutura de raiz e movimentação de todos os dados associados a esta mas também devido aos custos que envolve uma operação deste tipo. Uma possível solução é avaliar a utilização de linguagens para definição de infraestrutura como código (“Infrastructure-as-Code”) em conjunção com metodologias e tecnologias “DevOps” de forma a criar um mecanismo que permita flexibilizar um processo de migração entre diferentes infraestruturas de computação em nuvem, especialmente se for contemplado desde o início de um projecto. Uma metodologia “DevOps” devidamente estruturada quando combinada com definição de infraestrutura como código pode permitir um controlo mais integrado de recursos na nuvem uma vez que estes podem ser definidos e controlados através de linguagens específicas e submetidos a processos de automação. Tais definições terão de ter em consideração o que existe disponível para suportar as necessárias operações através das “API’s” das infraestruturas de computação em nuvem, procurando sempre garantir ao utilizador um elevado grau de controlo sobre a sua infraestrutura e um maior nível de preparação dos passos necessários para recriação ou migração da infraestrutura caso essa necessidade surja, integrando de certa forma os recursos de computação em nuvem como parte do modelo de desenvolvimento. Esta dissertação tem como objetivo a criação de um modelo de referência conceptual que identifique formas de migração de infraestruturas de computação procurando ao mesmo tempo uma maior independência do fornecedor de serviço com recurso a tais mecanismos, assim como identificar possíveis constrangimentos ou impedimentos nesta aproximação. Tal modelo poderá ser referenciado desde o início de um projecto de desenvolvimento caso seja necessário contemplar uma possível necessidade futura de alterações ao nível da infraestrutura ou de fornecedor, com base no que as “API’s” disponibilizam, de modo a facilitar essa operação.info:eu-repo/semantics/publishedVersio

Käytettävyyden ja kehityksen modernisointi mikropalveluilla

Vanhat ohjelmistojärjestelmät, joilla tarkoitetaan vanhoja ja vanhentuneita ohjelmistoja joita on tehty vanhentuneilla työskentelytavoilla, ovat todellisuus jonka kanssa suurin osa ohjelmistokehitysyrityksistä joutuvat kamppailemaan. Vanhat työskentelytavat ja teknologiat aiheuttavat usein ohjelmiston kehityksen ja julkaisun hidastumista, sillä niiden jatkuvassa käytössä voi piillä yhteensopivuus, turvallisuus, skaalautuvuus sekä ekonomisia ongelmia, muiden ongelmien muassa. Ohjelmistojärjestelmien modernisointi, uudelleensuunnittelu ja refaktorointi voivat lievittää vanhoista järjestelmistä nousevia ongelmia, oli se sitten työskentelytapojen muutoksella, teknologioiden päivityksellä tai ohjelmistoalustojen vaihdolla. On olemassa monia teknologioita ja metodeja jotka voivat helpottaa ohjelmistojärjestelmien modernisointia, mukaanlukien siirto käyttämään erilaista arkkitehtuuria, uusien teknologioiden käyttöönotto ja ohjelmistokehityksen tapojen vaihto. Näillä teknologioilla ja metodeilla, ja modernisaatiolla yleensäkkin, on omat riskinsä ja haasteensa, jotka tulee ottaa huomioon onnistuneen modernisaation aikaansaamiseksi; Nämä strategiset huomiot ovat avaintekijöitä modernisaatiossa. Tämä opinnäytetyö tutkii ohjelmistojen modernisaatiota yleisellä tasolla kirjallisuusarvostelun kautta, ja käyttää tietyn yrityksen tapaustutkimuksen dataa, joka on kerätty kyselyjen ja yhtiön lokien kautta, katsoen mitä teknologioita, konsepteja ja strategioita tarvitaan onnistuneeseen modernisaatioon, ja mitä vaikutuksia modernisaatiolla on modernisoitavaan ohjelmistojärjestelmään loppukäyttäjien sekä ohjelmistokehittäjien näkökulmasta. Tämän tutkimuksen lopputulos paljastaa miksi modernisaatio on monimutkainen aihe jossa on monia haasteita, mutta joka samaan aikaan tarjoaa monia hyötyjä modernisoitavalle ohjelmistojärjestelmälle. Näitä tuloksia on parasta käyttää ohjeina siihen, mihin ongelmiin kannattaa keskittyä modernisoinnin aikana, pitäen mielessä tapaustutkimuksen rajoitetun soveltamisalan.Legacy software systems, which refers to old and likely outdated software applications and practices, are a reality that most software development companies have to contend with. Old practices and technologies are often at fault for slowing down development and deployment of software, as they can have compatibility, security, scalability and economic issues with their continued use, among other issues. Software modernization, reengineering and refactoring can alleviate the issues stemming from legacy systems, whether it be in the form of altering practices, updating technologies or changing platforms. There are many technologies and methods that can facilitate the modernization of a software system, including a move to using different architectures, specific newer technologies and changing the methods of working and developing the software system. These technologies and methods, and modernization in general, come with their own risks and challenges that must be considered for a successful modernization to take place; These strategic considerations are a key factor in modernization. This thesis will explore software modernization in general through literature reviews and as a case study for a specific company using data from surveys and the case company’s logs, with a look into the technologies, concepts and strategies required for a successful modernization, and what kinds of effects modernization can have on the software system being modernized, both from a user perspective as well as from a developer perspective. The end-result of this exploration reveals that modernization is a complex subject with many challenges, but that also offers benefits to the software system being modernized. These results are best used as a guideline on what issues should be concentrated on during modernization, with a mindful consideration for the limited scope of the case study represented within

Modernin Web-Sovelluksen Migraatio Pilviympäristöön

Web technologies have been evolving fast since the adaptation of the modern web, and new tools and frameworks keep on coming into existence. With rapidly evolving technologies, the risk of accumulating technical debt becomes more common and must be taken into account at various stages of a software project. At the same time, new ways of working are generalising throughout development teams to ensure the quality of these projects. The purpose of this thesis is to explore modern web technologies, methodologies, as well as different categories of technical debt that these might bring. It also takes a look into the public cloud and its most common cloud service providers and their services. Based on these, it proposes a strategy for bringing an existing web application onto a cloud environment. Based on the case study project and literature evaluation, it is concluded that any application undertaking any larger work would benefit from having its technical debt at a manageable level and codebase in a good shape. It is also seen that when dealing with modern technologies, said technical debt might accumulate more rapidly than with projects implemented with more established technologies. When it comes to hosting web applications on the cloud, it is concluded that while a platform migration might bring some benefits in itself, a larger restructuring and careful redesigning work might be called for in order to fully reap the benefits of the public cloud.Web-teknologiat ovat kehittyneet nopeasti modernin nettiympäristön myötä, ja uusia työkaluja sekä sovellusalustoja syntyy jatkuvasti. Nopeasti kehittyvien teknologioiden kanssa työskennellessä teknisen velan kerryttämisen riski yleistyy ja sitä pitää tarkkailla monessa eri sovelluksen elinkaaren osassa. Tämän työn tarkoituksena on tutkia moderneja web-teknologioita sekä metodologioita ja niiden mukana tulevan teknisen velan eri kategorioita. Työ tutkii myös julkipilveä alustana sekä tämän yleisimpiä palveluntarjoajia ja heidän tarjoamiaan palveluita. Näiden perustella ehdotetaan strategiaa, jolla modernin web-sovelluksen saa tuotua pilviympäristöön. Tapaustutkimuksen ja kirjallisuuskatsauksen perusteella todetaan, että mikä tahansa sovellus, jolla on edessä isompi työkokonaisuus, hyötyy siitä, että sen kerryttämä tekninen velka on hallittavalla tasolla sekä koodikanta hyvässä kunnossa. Nähdään myös, että työskennellessä modernien teknologioiden kanssa kyseinen tekninen velka saattaa syntyä nopeammin kuin projekteissa, joissa on käytetty pidempään olemassa olleita teknologioita. Web-sovellusten tarjoamisesta pilviympäristöissä voidaan todeta, että vaikka migratointityö voi tuoda itsessään joitain hyötyjä mukanaan, voi isompi uudelleenjärjestämis- ja suunnittelutyö olla paikallaan, jotta voidaan saada kaikki julkipilven hyödyt irti