Thursday, September 8, 2011

What do studies say about Agile?

Agile Studies
This is going to be a different posting.  This one will be organic and added to as I find other good bits of information.  I need something like this to make it easier to go over an inventory of studies.  I need this to solve my "searching for studies" impediment which comes up periodically.

Help me keep this up to date.  If you have an Agile paper you want cited, comment about it. 
Refactoring:
 Understanding the Economics of Refactoring
Abstract: A novel method for estimating the expected maintenance savings given a refactoring plan. This work is motivated by the increased adoption of refactoring practices as part of new agile methodologies and the lack of any prescriptive theory on when to refactor.
Lance's Summary:
  •  best to refactor code that is going to be changed a lot in the future, so pay attention to where your rate of change is and keep that code clean
  • a guideline is that your refactoring pays for itself after six times you needed to revisit the code and change it
Test Driven Development:

TDD Improves Quality
Abstract: A paper first published in the Empirical Software Engineering journal reports: "TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team." The study compared 4 projects, at Microsoft and IBM that used TDD with similar projects that did not use TDD.

Does Test-Driven Development Really Improve Software Design Quality?
David S. Janzen, California Polytechnic State University, San Luis Obispo Hossein Saiedian, University of Kansas
Lance's summary: TDD allows simpler design == less lines of code to do the same thing
Summary: Software developers are known for adopting new technologies and practices Software developers are known for adopting new technologies and practices

Test-Driven Development and Software Quality
Lance's summary: a blog that comments on the IEEE paper "Does Test-Driven Development Really Improve Software Design Quality."

Pair Programing:
A good summary about the practice along with a little satire at wikipedia.

The Costs and Benefits of Pair Programming
Alistair Cockburn & Laurie Williams

Lance's summary: Pair programing creates a lot of value over the total product lifecycle (higher code quality, lower defects, reduces team bottlenecks, and increases work satisfaction) at the cost of 15% more development time.

ABSTRACT
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.


Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise
Erik Arisholm, Member, IEEE, Hans Gallis, Tore Dyba ̊, Member, IEEE Computer Society, and Dag I.K. SjĂžberg, Member, IEEE

Abstract—A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. 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. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time.

All I Really Need to Know I Learned in Kindergarten
By Robert Fulghum (Fulghum 1988)
Lance's Comment: Not really a study, but important information for people interested in pairing studies.  This paper contains a lot of the behaviors needed for successful pair programming.

Abstract:
Share everything.
Play fair.
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt somebody.
Wash your hands before you eat.
Flush.
Warm cookies and cold milk are good for you.
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Take a nap every afternoon.
When you go out into the world, watch out for traffic, hold hands and stick together.
Be aware of wonder.

Pair Programming Testimonials
Abstract:
If you would like to share your pairing experiences or read about other people's, this is the place. Describe the good and bad of your experiences pairing to help others in a similar situation - just a paragraph or two would be great . . . what worked well, what didn't work so well, what kinds of things did you 'attack' together, tips and tricks, etc. A great example of a testimonial is by Ron Jeffries in the July/August 2000 IEEE Software page 25.




6 comments:

  1. I guess by "Studies" you mean something more than an opinion stated in a paper on the topic. I guess you mean some form of pier reviewed paper or experimental study. Typically living in academia land - right? I ask because I'd point you at Sutherland's Papers http://jeffsutherland.com/scrum_bibliography.htm

    But not sure if these would pass the bar... what do you think?

    ReplyDelete
  2. I like studies the most, but useful information in lieu of studies is good too.

    ReplyDelete
  3. See for example Laurie Williams et al, ‘Strengthening the Case for Pair Programming’, IEEE Software, July/August 2000 (online at http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PDF)

    ReplyDelete
  4. The Effects of Pair-Programming on Performance in an Introductory ...

    http://www.google.com/url?sa=t&source=web&cd=6&ved=0CD0QFjAF&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.89.6834%26rep%3Drep1%26type%3Dpdf&rct=j&q=%22Developing%20In%20Pairs%22&ei=K79uTvqgNKf9sQLf5fW5CQ&usg=AFQjCNEL5KXkBDlHfNmb-4eymVsVhgLzTQ&sig2=ON3B_PGZqRHCp344jigKJw&cad=rja

    ReplyDelete
  5. Do testers have to be coders also?

    http://testobsessed.com/2010/10/20/testers-code/

    "The bottom line is that our numbers indicate approximately 80% of the job ads you’d find if searching for jobs in Software QA or Test are asking for programming skills."

    ReplyDelete
  6. Here is a nice blog about Pair Programming Benefits: http://pragprog.com/magazines/2011-07/pair-programming-benefits

    ReplyDelete