What is Code?

Software has been around since the 1940s. Which means that people have been faking their way through meetings about software, and the code that builds it, for generations. Now that software lives in our pockets, runs our cars and homes, and dominates our waking lives, ignorance is no longer acceptable. The world belongs to people who code. Those who don’t understand will be left behind.

This issue comprises a single story devoted to ­demystifying code and the culture of the people who make it. There’s some technical language along with a few pretty basic mathematical concepts. There are also lots of solid jokes and lasting insights. It may take a few hours to read, but that’s a small price to pay for adding decades to your career.

—Josh Tyrangiel

Read Paper

Managing Technical Debt: Insights from Recent Empirical Evidence

Managing Technical Debt: insights from Recent Empirical Evidence by Narayan Ramasubbu, Chris F. Kemerer, and C. Jason Woodard

Technical debt refers to maintenance obligations that software teams accumulate as a result of their actions. Empirical research has led researchers to suggest three dimensions along which software development teams should map their technical-debt metrics: customer satisfaction needs, reliability needs, and the probability of technology disruption.

Read Paper

Contact the Authors:

Trade-offs Between Productivity and Quality in Selecting Software Development Practices

Trade-offs between Productivity and Quality in Selecting Software Development Practices by Alan MacCormack, Chris F. Kemerer, Michael A. Cusumano, and Bill Crandall 

Choosing appropriate practices for a project can be hard, given the various dimensions of performance each claims to optimize. Using data from 29 projects, this study examines the impact of eight development practices on both productivity and quality. Results suggest managers should choose a coherent system of practices on the basis of the specific objectives the software must meet.

Read Full Article

Faculty Member Outlines Values of Software System Architecture

Faculty Member Outlines Value of Software System Architecture by Alan MacCormack

Over the last 10 to 15 years, even the most traditional of industries have come to rely on software, for everything from inventory control to vehicle navigation. The average automobile today has more software than the first Apollo moon rocket. Your garden variety microwave may even have an algorithm for cooking popcorn to fit your specific tastes. Despite this dramatic increase in the pervasiveness and importance of software, however, many companies lack a fundamental understanding of the architecture underlying their code. This problem costs firms millions of dollars per year.

Read Full Article

Technical Debt: From Metaphor to Theory and Practice

Technical Debt: From Metaphor to Theory and Practice by Philippe Kruchten, Robert L. Nord, and  Ipek Ozkaya 

The metaphor of technical debt in software development was introduced two decades ago by Ward Cunningham to explain to nontechnical product stakeholders the need for what we call now “refactoring.” From the original description—”not quite right code which we postpone making it right” —various people have used the metaphor of technical “debt” to describe many other kinds of debts or ills of software development, encompassing broadly anything that stands in the way of deploying, selling, or evolving a software system or anything that adds to the friction from which software development endeavors suffer: test debt, people debt, architectural debt, requirement debt, documentation debt, or just an amorphous, all-encompassing software debt. Consequently, the concept of technical debt in software development has become somewhat diluted lately. Is a new requirement, function, or feature not yet implemented “requirement debt”? Do we call postponing the development of a new function “planning debt”? The metaphor is losing some of its strength.

To make some progress, we need to go beyond debt as a “rhetorical concept.” We need a better definition of what constitutes technical debt and some perspective or viewpoints that let us reason across a wide range of technical debt. In short, we need a theoretical foundation.

Read Full Article

More Than the Sum of Its Parts: The Impact of Modularity on the Computer Industry

More Than the Sum of Its Parts: The Impact of Modularity on the Computer Industry

The “power of modularity,” write HBS Dean Kim Clark and Professor Carliss Baldwin in their new book, rescued the computer industry from a problem of nightmarish proportions and made possible remarkable levels of innovation and growth in a relatively short period of time.

Read Full Article

Technical Debt in Firefox and Chromium

Technical debt in Firefox and Chromium by Ali Almossawi 

In his previous article How maintainable is the Firefox codebase, the author discussed how an important quality attribute, namely, maintainability, could be quantified. It looked at how Firefox was doing with respect to those measures and suggested some preliminary findings. The aim of this second, much shorter, article is to provide better context by comparing Firefox to another popular and complex software system.

Read Full Article

How Maintainable is the Firefox Codebase?

How maintainable is the Firefox codebase? by Ali Almossawi

This work explores a particular facet of quality in Firefox, namely, maintainability. By appealing to the explanatory powers of five practical measures of architectural complexity, and with the aid of static analysis and network manipulation tools, we arrive at some preliminary findings. We find that 21% of files in Firefox are highly interconnected, a value that went up significantly following version 3.0. We find that making any change to a randomly selected file can, on average, directly impact 10 files and indirectly impact over 2,300 files. We see that files’ internal complexity is on average going down. Their external complexity as measured by direct dependencies is also going down, whereas their external complexity as measured by propagation cost has remained steady. With respect to process, we find that the switch to the rapid release cycle from version 5.0 onwards had a positive impact on quality. Though the analysis reveals no imminently alarming red flags when it comes to maintainability, it does shine light on a number of issues that would be worth investigating. An upcoming article will take a closer look at how Firefox’s architectural measures of complexity compare to those of other open-source projects.

Read Full Article

Evolution of the Firefox Codebase

Evolution of the Firefox Codebase by Ali Almossawi 

Evolution of the Firefox Codebase presents a set of metrics for all releases of Firefox that are indicative of quality and allows one to inspect them through one of several views. By looking at changes in these metrics, one can see the evolution of the Firefox codebase over time. This work is also be useful as a retrospective, investigative tool to help infer when, say, architectural issues may be the cause for unfavorable user sentiment following a release. Metrics such as lines-of-code (LOC) and cyclomatic complexity are widely used in industry, whereas others like propagation cost are based on some of the more recent research to come out of academia.

Read Full Article

SDM Best Thesis Analyzes Costs of Software System Complexity

SDM Best Thesis analyzes costs of software system complexity by Andrei Akaikine

Maintaining a complex system at a “good enough” level  of functionality comes at a cost. In systems where stability is
paramount, personnel dealing with small emergencies traditionally rely on “Band-Aid” fixes that increase complexity and heighten the risk of destabilizing the whole system with each new modification, however minor.

Andrei Akaikine’s thesis focuses on the following three questions:
• Is there a relationship between engineering efforts required for a basic
maintenance task and the overall software system complexity?
• Are any components more susceptible than others to change during
system maintenance tasks?
• Can the redesign of a system be economically justified?

Read Full Article