The effects of the business model on object-oriented software development productivity

Abstract

We intend to demonstrate that if the business model cannot adjust to new technology, by recognizing a) its limitations, b) the ability of the organization to control it, and c) by adjusting its deadlines to take advantage of the methodology potentials, it is unlikely that an investment in the technology will result in real productivity benefits.As software development cycles shorten, and software markets become more competitive, improved software development productivity continues to be a major concern in the software industry. Many believe that object-oriented technology provides a breakthrough solution to this problem, but there is little quantitative evidence for this belief. Furthermore, most studies related to object-oriented productivity do not consider it in conjunction with the business constraints under which the software is developed. Business models tend to focus on cost and calendar events and tend to form deadlines that are governed by marketing windows and pressures. In this paper we explore the relationship between the business model and the productivity that a software development methodology can achieve in a commercial environment. We first examine empirical data from several commercial products developed under the same business model and an iterative software development process. The results indicate that lack of incentives for early completion of intermediate project tasks, and a rigorous enforcement of final project deadlines, may trigger Parkinson's Law delays and negatively affect software development productivity, especially when projects are developed using object-oriented methods. We then model and simulate the impact of software task completion incentives and imposed deadlines on productivity that might be expected from potentially high-productivity technology, such as object-orientation. We show how and why some common business practices might lower project productivity and project completion probability. We also discuss to what extent poor software process control and/or use of immature technology compounds the problem.

Productivity of agile teams: an empirical evaluation of factors and monitoring processes

“…Although several other studies [Blackburn et al, 2000, Brooks, 1995 consider team size as a negative factor because of the high number of necessary communication links, Smith et al [2001] claim that large teams may also be productive, if the developers work independently. Schedule compression [Boehm, 2000, Potok andVouk, 1998] or expansion [Blackburn et al, 2000, Maxwell et al, 1996 may also affect productivity negatively, as well as staff turnover [Abdel-Hamid, 1989]. [ Maxwell et al, 1996, Vosburgh et al, 1984 Schedule compression and expansion.…”

“…[ Blackburn et al, 2000, Boehm, 2000, Maxwell et al, 1996, Potok and Vouk, 1998 Team composition including team size, team collocation, and staff turnover.…”

A model of correlated team behaviour in a software development environment

“…The basic model is described in detail in [Pot96,Pot97]. In the context of this paper we define average productivity of a software professional in thousands of lines of code ( KLOC) per person-month.…”

“…Since the tasks are executed by the members of a software development team, and task parameters, such as the task duration, can be a strong function of the capabilities of a team executing the task, and/or of the business model influences [Pot97], a key issue becomes the extent and the duration of the influence team behavior may have on the project parameters. For example,: "Is it valid to assume that software development teams act independently from task to task in a project?"…”

“…A very natural (and obvious) assumption is that a strong (e.g., skillful) team will exhibit high-productivity over all project tasks, while a weak team will exhibit low productivity over all tasks. Less obvious is that the business model decisions can reduce the effectiveness of a "good" team [Pot97], and that on projects where one operates on sub-optimal schedules, it may be better not to have "good" and "other" teams, but that it might be more productive to randomize team composition and skills. That is, how to answer questions such as "Given a pool of people, is it better to select few very good teams, and a few not so good teams, or is better to select all team members in such a way that all teams have nearly the same "average" capabilities"?…”