A new pair programming study (Arisholm et al. 2007) indicates that that the practice neither increases quality or reduces costs, in general.
“The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly.”
In specific contexts, like junior programmers pairing on complex tasks, pair programming results in significant increases in quality. However, in other contexts the increase in quality, if any, comes at a high cost. The study doesn’t appear to support the conclusions described in earlier XP research. Specifically, that a team could expect “a 15% increase in development cost for a 15% improvement in quality”. This earlier study used students rather than professional programmers and the strength of some of the researchers’ techniques and conclusions have been questioned.
My own personal experience is that I enjoy pair programming for some activities and in some contexts, but not in all contexts. Continue Reading »
In a recent article I wrote about preferring Effective Software Development (ESD). I prefer being effective over being labeled as “agile” (whatever that might mean to you personally). This preference raises many questions for me. How do I define effectiveness? How do I know if I’m being effective or not? How can I become more effective? Is there any way I can help those around me be more effective? As you can imagine, these questions lead to many others.
I like the Wikipedia description of effectiveness. The description defines positive effectiveness in terms of efficacy and efficiency. Efficacy is the ability to produce a desired effect or achieve a goal. In a software development context, that might mean the ability to produce timely business value. Efficiency is the amount of effect that can be produced with a given amount of resources such as time or number of developers.
I think of efficacy as a primary component of effectiveness and efficiency as a secondary component. Continue Reading »
There’s been much discussion and debate in various forums about the evolving use of the word “agile” to describe software development. Some people involved in the discussion have suggested creating a new term to replace “agile”. In most cases, I don’t support replacing terminology. However, the term “agile” seems to have suffered so much semantic diffusion that it’s practically meaningless.
Speaking for myself, I am interested in the effectiveness of my software development activities, where “effective” must be evaluated in a specific context. In Effective Software Development (ESD), I want to have a wide range of resources (practices, tools, resources) available to me and I want to understand the tradeoffs associated with using these resources in various contexts. I’m not interested in labeling myself or my team as an “XP Team” or a “Scrum Team”. Who cares about the label if the team or organization is not effective.
I’ve seen several ESD teams who have used practices similar to the established named agile methodologies. However, they typically used a hybrid of those sets of practices. They couldn’t be labeled as Scrum or XP or Crystal or whatever. Their process was agile — but without a name. And they were effective.
I recommend not worrying about whether your team or organization deserves the fashionable “agile” label. The important question is “are you effective?”. Ask yourself what “effectiveness” means in your organization and then evaluate if your team meets that criteria. This isn’t an optimization problem. If you are effective enough, then focus on delivering value. If not, study the development options available to you and decide which ones will help you and your team be more effective. You might decide on a “ready-to-go” combination of practices like XP or you could experiment with a combination of techniques that are a custom fit for your team. Evaluate the results and adjust as necessary until you become an ESD team.
I’ve seen recent discussions in various forums about the meaning of XP values and principles. Here are my current working definitions.
Values. A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.
Principles. Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the XP “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.
Practices. A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.
Continue Reading »
Why do some teams allow technical debt to accumulate and others are better at recognizing the debt and actively reducing it? One possibility is a skill difference. This skill difference could be the result of differing experience or differences in intelligence. In any case, the theory is that a more experienced, skilled team will generally be better at managing the quality of their software. This is certainly logical. However, I think there may be another aspect to consider. Continue Reading »
