Case Study Papers (Google Scholar will be happy to retrieve this for you) -------------- [Andersen and Morch 2009] Renate Andersen and Anders Morch, Mutual development: A case study in customer-initiated software product development 2nd International Symposium on End-User Development (LNCS 5435), Siegen, Germany, Springer-Verlag Berlin Heidelberg, March 2-4, 2009, pp. 31-49.  Educational about different models of end-user co-development, eg meta-design vs. modding vs. tailoring. Also good case study methodology. (Co-development of professionals with EUPs was pretty much the theme of this conference.) end-user programming, co-development (can obtain from IEEE or ACM library) ------------- [Aranda and Venolia 2009] Jorge Aranda and Gina Venolia, The Secret Life of Bugs: Going Past the Errors and Omissions in Software Repositories, International Conference on Software Engineering, Vancouver, Canada, May 16-24, 2009, pp. 298-308. Field study of coordination activities. Great example of case study research and rigor. Results: even simple bugs need sociotechnical knowledge that cannot be solely extracted thru automation of repositories, and such automation provides incomplete and often erroneous accounts of bug coordination. (can obtain from IEEE or ACM library) ----------------------- [Bird et al. 2009] Christian Bird, Nachiappan Nagappan, Premkumar Devanbu, Harald Gall, Brendan Murphy, Does distributed development affect software quality? An empirical case study of Windows Vista, International Conference on Software Engineering, Vancouver, Canada, May 16-24, 2009, pp. 518-528. Main result: distributed devel didn't have a huge effect. But this is probably because the way it is done at MS takes into acct prev researchers’ implications for design. eg there are daily electronic/phone meetings, they've all met face-to-face, they all make similar salaries and bens, there is end-to-end ownership of code components, etc. Distinguished paper award. (can obtain from IEEE or ACM library) ------------------ [Capiluppi et al. 2007] A. Capiluppi, J. Fernandez-Ramil, J. Higman, H. C. Sharp, and N. Smith, An empirical study of an agile-developed software system, International Conference on Software Engineering, Minneapolis, MN, May 20-26, 2007, pp. 511-518.  Good example of a case study paper. Features triangulation, rival explanations, and careful attention to their evidence chains. On extreme programming in the real world. A combination of studying historical records, observational study, records, comments, qual + quant.  (can obtain from ACM library) -------------- [Cherubini et al. 2007] Mauro Cherubini, Gina Venolia, Rob DeLine, Andrew Ko, Let’s go to the whiteboard: How and why software developers use drawing, ACM Conference on Human Factors in Computing Systems, San Jose, CA, Apr 28-May 3, 2007, pp. 557-566. They used semi-structured inteviews as their method, and their methodology is a good example of this technique, so good reading for anyone doing interviews in the case study course. (can obtain from IEEE or ACM library) --------------- [Hulkko and Abrahamsson 2005] Hanna Hulkko and Pekka Abrahamsson,  A multiple case study on the impact of pair programming on product quality, International Conference on Software Engineering, St. Louis, MO, pp. 495-504, May 15-21, 2005. Case studies to see how pair programming results from prior research settings play out in the real world.  (can obtain from IEEE or ACM library) ----------------------- [Ko et al. 2007] Andrew Ko, Robert DeLine, Gina Venolia, Information needs in collocated software development teams, International Conference on Software Engineering, Minneapolis, MN, May 20-26, 2007, pp. 344-353. Great paper about information needs.  Also evidence of good case study methodology. (can obtain from IEEE or ACM library) -------------- [Rigby et al. 2008] Peter Rigby, Daniel German, and Margaret-Anne Storey, Open source software peer review practices: A case study of the Apache server, International Conference on Software Engineering, Leipzig, Germany, May 10-18, 2008, pp. 541-550. This is about code inspection.  Apparently it’s heavily used in open source, which is sort of remarkable since paid developers complain about the time it takes to do code inspections. Paper digs into practices and effectiveness of doing this in OSS. Bottom line: works pretty well. The number of inspectors seems to be most commonly one or two. Finally, they contribute a theory (set of connected hypotheses) about what/why it works.