A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

Video Game Development in a Rush: A Survey of the Global Game Jam Participants

Video game development is a complex endeavor, often involving complex software, large organizations, and aggressive release deadlines. Several studies have reported that periods of "crunch time" are prevalent in the video game industry, but there are few studies on the effects of time pressure. We conducted a survey with participants of the Global Game Jam (GGJ), a 48-hour hackathon. Based on 198 responses, the results suggest that: (1) iterative brainstorming is the most popular method for conceptualizing initial requirements; (2) continuous integration, minimum viable product, scope management, version control, and stand-up meetings are frequently applied development practices; (3) regular communication, internal playtesting, and dynamic and proactive planning are the most common quality assurance activities; and (4) familiarity with agile development has a weak correlation with perception of success in GGJ. We conclude that GGJ teams rely on ad hoc approaches to development and face-to-face communication, and recommend some complementary practices with limited overhead. Furthermore, as our findings are similar to recommendations for software startups, we posit that game jams and the startup scene share contextual similarities. Finally, we discuss the drawbacks of systemic "crunch time" and argue that game jam organizers are in a good position to problematize the phenomenon.Comment: Accepted for publication in IEEE Transactions on Game

A pilot study of test driven development

textTest Driven Development is a software technique which uses automated unit tests to drive software design and to force decoupling of dependencies. This report describes the pilot study that was conducted to understand Test Driven Development process and to evaluate its pros and cons before adopting it completely across the software team. The goal of the pilot study was to use TDD principles to build part of a real life software project - in particular, to completely implement 3 user stories - and to evaluate the resulting software. The main questions being discussed are - Is it feasible to adopt TDD in the development of a real life system with databases and UI? How easy is it to convert a user story into a set of unit tests? Can a set of unit tests adequately represent a user story or are requirements lost in translation?Electrical and Computer Engineerin

A Case Study on the Adoption of Measurable Agile Software Development Process

Agile methodologies for software development meet the challenges of the current highly dynamic and competitive business environment. The aim of this case study is to improve existing software development process in a project for the public administration, following the basic principles of agile methodologies. Appropriate metrics for continuous evaluation of the process are introduces to help evaluating and improving the methodology. The main objectives of the new methodology are to improve communication with customers, to improve communication among different distributed teams and inside the teams, and to continuously evaluate the way software is developed through selection and usage of software metrics. The paper presents the results of methodology adoption in two subsequent iterations of a real project

Using Agile Software Development Practices in a Research Oriented Distributed Simulation

Although sometimes controversial, agile methodologies have proven to be a viable choice for some software development projects. Projects suited to agile methodologies are those that involve new technology, have requirements that change rapidly, and are controlled by small, talented teams. Much literature about agile software development leans towards business products and non-government entities. Only a handful of literature resources mention agile software development being used in government contracts and even fewer resources mention research projects. NASA\u27s Airspace and Traffic Operations Simulation (ATOS) is a research oriented simulation that doesn\u27t follow the traditional business project mold. In an effort to gain a better understanding if agile could be used effectively in a NASA contract for a research oriented simulation project, this research looked at what agile practices could be effectively used to help gain simulation reliability while simultaneously allowing routine maintenance, current experiment support, new modeling additions, and comprehensive architectural changes

Challenges of deploying a scalable user generated content platform for young people

Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2008.Includes bibliographical references (leaf 39).ScratchR, a user generated content management platform, was developed by the Lifelong Kindergarten group at the MIT Media Lab. ScratchR lets users share projects developed with the Scratch programming language. This thesis involves technical improvements made to ScratchR from August 2007 to August 2008. Improvements include the addition of a comment reply system, the improvement of the gallery system, the addition of AJAX functionality, the creation of administration tools and the addition of a peer review system for comments and tags. These features augment the user experience of the Scratch online community by improving usability and by creating a friendlier online learning environment.by Han Xu.M.Eng

Technical Debt Management: Definition of a Technical Debt Reduction Software Engineering Methodology for SMEs

In the past two decades, the metaphor of technical debt has gained significant importance in the field of software engineering. In general, the term is used to describe scenarios when instead of providing a proper solution for a given task, a sub-optimal implementation is used in order to gain short term benefits. Unfortunately, this kind of decisions can - and most of the time do - result in increased maintenance costs and poor evolvability in the long run. Over time, software practitioners further refined the initially source code-focused concept and started to apply the metaphor for a much wider range of software engineering inefficiencies, such as architectural defects, inappropriate documentation or low test coverage. Due to its similarity to financial debt, the analogy has also become a valuable communication tool in situations when there are less technical people involved in discussions. This master's thesis defines a technical debt reduction methodology, which can help SMEs to control the accumulation of technical debt. The proposed methodology can be thought of as a set of steps and good practices that facilitate the long-lasting productivity and profitability of SMEs. Since this field of research is relatively new, the need for publications addressing the topic is still rather high. Due to its numerous negative effects, it is crucial for companies to keep their debt levels as low as possible, which requires a systematic way of managing technical debt. Besides providing such a methodology, the document also intends to raise awareness about the nature and dangers of taking on unreasonable amounts of debt by examining the most important characteristics of the phenomenon. Finally, the thesis presents an industrial case study as well, which aims to showcase how some of the most necessary steps can be taken in practice