to understand the world: • How do people manage to change their soMware? Nurtured by challenges faced during soMware maintenance Maintenance Engineering research Help to change the world • How can we support people changing their soMware? Nurtured by soMware evoluCon research results 3 hWps://flic.kr/p/edchNL, steveolmstead
Scalable, query-‐able, offline mirror of data from GitHub REST API. • Data since 2012 • 5.9 TB json in MongoDB • 600M rows in MySQL • 1 GB per hour collected 8 Georgios Gousios: The GHTorent dataset and tool suite. MSR 2013: 233-‐236 Georgios Gousios, Diomidis Spinellis: GHTorrent: Github's data from a firehose. MSR 2012: 12-‐21
• 95-‐percenCle = 21 • Rails / Homebrew: • > 10,000 pull requests 0 1000 2000 3000 100 10000 Number of pull requests (log) Number of projects 9 Georgios Gousios, MarCn Pinzger, Arie van Deursen. An exploratory study of the pull-‐based soMware development model. ICSE 2014: 345-‐355
– depends on how hot area of code is • Time to merge: – depends on test density of project • Pull request rejecCon: – caused by (lack of) task arCculaCon 13 Georgios Gousios, MarCn Pinzger, Arie van Deursen. An exploratory study of the pull-‐based soMware development model. ICSE 2014: 345-‐355
received one pull request per week in 2013. • Generated performance reports • Sent personalized email to integrators. • … asked a carefully designed set of quesAons. • and received 750 responses in 2 weeks. 15 Georgios Gousios, Andy Zaidman, Margaret-‐Anne Storey, and Arie van Deursen. Work PracCces and Challenges in Pull-‐Based Development: The Integrator’s PerspecCve. Report TUD-‐SERG-‐2014-‐013
‘hey, I added a LOT of features and fixes ALL AT ONCE!’ R255: Telling people that something is wrong without hurCng their feelings R449: Dealing with loud and trigger-‐happy developers.
multiple communication channels reaching consensus poor notifications project speed process ignorance timezones coordination among contributors coordination among integrators impact politeness asking more work bikeshedding hit 'n' run RPs poor documentation age syncing feature isolation developer availability conflicts differences in opinion motivating contributors generalizing solutions tools git knoweledge size review tools testing responsiveness maintain vision volume explaining rejection reviewing maintaining quality time 0.0 2.5 5.0 7.5 Percentage of responses rank Top Second Third Biggest Challenges when Working with Pull Requests
locality quality check automation clear purpose performance commit quality added value test manual size project conventions author reputation experience understandability documentation test result code review code quality test coverage style conformance 0 4 8 12 Percentage of responses rank Top Second Third Factors developers examine when evaluaCng quality of contribuCons
Only if all bug fix pull requests are treated. R490: The lower the number of lines/files changes, the more likely I am to process it first. R82: If I know the person, they get high priority. Sorry, strangers.
with source • As in Maven Central on July 30, 2011 • With resolved usage data 27 Steven Raemaekers, Arie van Deursen, Joost Visser. The maven repository dataset of metrics, changes, and dependencies. MSR 2013: 221-‐224
1 of Lib1 1. public class Lib1 { 2. public void foo() {...} 3. public int doStuff() {...} 4. } 1. // method2 uses foo & doStuff 1. public class System1 { 2. public void method2() { 3. Lib1 c1 = new Lib1(); 4. c1.foo(); 5. int x = c1.doStuff(); 6. anUnrelatedChange(); 7. }} 1. // Version 2 of Lib1 1. public class Lib1 { 2. public void foo(int bar) {...} 3. public String doStuff() {...} 4. } 1. // method2 uses foo & doStuff 1. public class System1 { 2. public void method2() { 3. Lib1 c1 = new Lib1(); 4. c1.foo(); 5. int x = c1.doStuff(); 6. } 7. }
class, method, or field Changes: Nr of parameters, or change in field / parameter / return type 29 “Pre-‐exisAng client binaries must link and run with new releases of the component without recompiling.” -‐-‐-‐ the CLIRR tool. flickr.com/photos/dullhunk/
projects of C, not built by S. • Baseline (n=16): Finalized projects of C, build by S, in scope. • Pilot (n=10): Strictly size-‐based pricing, 6 month period • Forecast (n=29): Price agreements based on funcConal size 37 Hennie Huijgens, Georgios Gousios, Arie van Deursen. Pricing via FuncConal Size: A Case Study of 77 Outsourced Projects. Tech report TUD-‐SERG-‐2014-‐012.
more detail in order to get the right FuncCon Points […] This helps in early detecCon of issues and resoluCon. P5: FuncCon point analysis is not applicable to projects where more tesCng efforts are required for less development changes. P3: Too many small projects are negaCve for Company C due to economy-‐of-‐scale effects.
language of change management • Give change first-‐class treatment at all levels • Parallelize / de-‐linearize change where possible 42 flickr.com/photos/wackybadger/
not an objecCve • True understanding comes from talking to people busy geYng their hands dirty • QualitaCve research is hard work • ObligaCon to share our results 45
avandeursen
nttcom
aranciap
okoso
rudorudo11
sofievl
frandle256
comfortdesignlab
iwiwi
shunk031
tsantalis
noppoman
ufuk
dougneiner
jnunemaker
geeforr
aki_iinuma
eileencodes
aleyda
csswizardry
cromwellryan
mojombo
stephaniewalter
jonrohan
