Much recent research has pointed to the critical role of architecture in the development of a firm's products, services and technical capabilities. A common theme in these studies is the notion that specific characteristics of a product's design -for example, the degree of modularity it exhibits -can have a profound effect on among other things, its performance, the flexibility of the process used to produce it, the value captured by its producer, and the potential for value creation at the industry level. Unfortunately, this stream of work has been limited by the lack of appropriate tools, metrics and terminology for characterizing key attributes of a product's architecture in a robust fashion. As a result, there is little empirical evidence that the constructs emerging in the literature have power in predicting the phenomena with which they are associated. This paper reports data from a research project which seeks to characterize the differences in design structure between complex software products. In particular, we adopt a technique based upon Design Structure Matrices (DSMs) to map the dependencies between different elements of a design then develop metrics that allow us to compare the structures of these different DSMs. We demonstrate the power of this approach in two ways: First, we compare the design structures of two complex software products -the Linux operating system and the Mozilla web browser -that were developed via contrasting modes of organization: specifically, open source versus proprietary development. We find significant differences in their designs, consistent with an interpretation that Linux possesses a more "modular" architecture. We then track the evolution of Mozilla, paying particular attention to a major "re-design" effort that took place several months after its release as an open source product. We show that this effort resulted in a design structure that was significantly more modular than its predecessor, and indeed, more modular than that of a comparable version of Linux.Our findings demonstrate that it is possible to characterize the structure of complex product designs and draw meaningful conclusions about the precise ways in which they differ. We provide a description of a set of tools that will facilitate this analysis for software products, which should prove fruitful for researchers and practitioners alike. Empirically, the data we provide, while exploratory, is consistent with a view that different modes of organization may tend to produce designs possessing different architectural characteristics. However, we also find that purposeful efforts to re-design a product's architecture can have a significant impact on the structure of a design, at least for products of comparable complexity to the ones we examine here.2

U ncertain and dynamic environments present fundamental challenges to managers of the new product development process. Between successive product generations, significant evolutions can occur in both the customer needs a product must address and the technologies it employs to satisfy these needs. Even within a single development project, firms must respond to new information, or risk developing a product that is obsolete the day it is launched. This paper examines the characteristics of an effective development process in one such environment-the Internet software industry. Using data on 29 completed development projects we show that in this industry, constructs that support a more flexible development process are associated with better-performing projects. This flexible process is characterized by the ability to generate and respond to new information for a longer proportion of a development cycle. The constructs that support such a process are greater investments in architectural design, earlier feedback on product performance from the market, and the use of a development team with greater amounts of "generational" experience. Our results suggest that investments in architectural design play a dual role in a flexible process: First, through the need to select an architecture that maximizes product performance and, second, through the need to select an architecture that facilitates development process flexibility. We provide examples from our fieldwork to support this view.

Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of shortterm expedients. The technical debt metaphor is gaining significant traction in the agile development community as a way to understand and communicate such issues. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. We argue that the software engineering research community has an opportunity to study and improve this concept. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. Therefore, we propose managing technical debt as a part of the future research agenda for the software engineering field

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that this organization produces.Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and even the path of industry evolution.We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures.Specifically, loosely-coupled organizations will develop more modular designs than tightly-coupled organizations.We test this hypothesis, using a sample of matched-pair products.We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial -up to a factor of eight, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.

No abstract

There is increasing interest in the literature about the notion of a contingent approach to product development process design. This interest stems from the realization that different types of projects carried out in different environments are likely to require quite different development processes if they are to be successful. Stated more formally, a contingent view implies that the performance impact of different development practices is likely to be mediated by the context in which those practices operate. This article provides evidence to support such a view.Our work examines whether projects in which the development process matches the context achieve superior performance. We focus on two sources of uncertainty that generate challenges for project teams: platform uncertainty, reflecting the uncertainty generated by the amount of new design work that must be undertaken in a project; and market uncertainty, reflecting the uncertainty faced in determining customer requirements for the product under development. We develop hypotheses for how these sources of uncertainty are likely to influence the relationships between a number of specific development practices and performance. We then test these hypotheses using data from a sample of 29 Internet software development projects.Our results provide evidence to support a contingent view of development process design. We show that in projects facing greater uncertainty, investments in architectural design, early technical feedback, and early market feedback have a stronger association with performance. The latter relationships are influenced by the specific sources from which this uncertainty stems: platform uncertainty mediating the impact of early technical feedback and market uncertainty mediating the impact of early market feedback. Our results also indicate that while greater uncertainty is associated with making later changes to a product's design, this practice is not associated with performance.Our findings suggest that managers carefully must evaluate both the levels and sources of uncertainty facing a project before designing the most appropriate process for its execution. In particular, they should explore the use of specific development practices based upon their usefulness in resolving the specific types of uncertainty faced. Importantly, these decisions must be made at the start of a project, with purposeful investments to create a process that best matches the context. Reacting to uncertainty ex-post, without such investments in place, is unlikely to prove a successful strategy.

No abstract

No abstract