2 page accademic paper about CSL work
Tue Dec 1 12:45:16 AM EDT 2009
We're going to this conference: http://www.hfoss.org/hfoss2010/ Thanks to Bob Lechner for pointing out that it existed. Thanks to Fred Martin for pointing out that we'll have better conversations if we submit a "poster summary" or "Position Paper". Thanks to Laura MacNeil for fixing some really ugly bits in the minutes before the submission deadline. From what I understand this kind of academic paper isn't a competitive thing. Still it was daunting for me. Then again, freshman composition was daunting for me even after the 4th semester of it. Pasted below is the unformatted paper. It is submitted and the deadline is past, so the chances of fixing problems are slim. Still, I'd be grateful for opinions. I'm particularly interested in what volunteer / student coders have to say. Just because a Fearless Leader (TM) says our atmosphere is relaxed and cooperative mean that it is. #################### INTRODUCTION The Community Software Lab's Open Source software drives two websites: MVHub.com and the NorthShorePort.org Every month, we provide more than 1,000 referrals to services like homeless shelters, pregnancy testing and food pantries. We are working to make our software usable for other sites and other organizations. Our project has worked with student coders for 7 years. However, our goal is better software not education. We help people learn not because we care for them, but because learning helps them write better software for us and we don't have the money to pay experienced coders. Right now hours invested in mentoring return roughly the same amount of good code we could have gotten by spending the time writing it ourselves. We hope to do better. Our continued commitment comes from our hope that: 1) Improving our structures will make good student code easier 2) Improving our structures will make good code from everyone easier 3) Involving students will help our broader social goals. Most significantly, since last year, We've moved from spending 80% of our technical time in system administration and web hosting to spending 90% of our technical time on software development. It is also our hope that this narrower focus will yield better results. EDUCATION IS NOT OUR GOAL We are not an educational institution. If the field of software engineering education improves and our project doesn't have better code, we have failed. Our learning and teaching is radically different from that of educators. We learn what we need to know to solve our current software problem cleanly. If a student is working on a problem, we do just enough teaching to help them over the hump. Student Code Is of Low Quality Students write code that will be used only once, late at night by a sleepy graduate student grader. The simple rules of craft do not apply. The test data will always be in the same directory as the executable and the executable will always be run from its directory. Checking the result code for "open" is not required. It is a solid satisfaction to share our craft and see somebody else's contribution increase. This pleasure is diminished because as peoples' skills increase, so do their odds of getting a paying day job and leaving us. OUR CURRENT STRUCTURES At any time, we'll work with anyone who can figure out how to pull a bzr branch from http://launchpad.net/mvhub/ and submit a patch to us. We have 6 spots for local volunteers willing to commit 4 or more hours per week in our office. When a spot opens up, we accept anyone who can do the very simple coding test at: http://thecsl.org/go/vol/ When a new volunteer arrives, we toss them the "Learning Perl" book. In about 2 weeks, most people report back that they've learned enough Perl to get started. We help them setup an account on http://launchpad.net, create an account on our servers, and do a brief run through of bzr version control software and launchpad bug tracking. For the first project we'll sit down together, go over the problem & create or update the rough written project notes/bug report. For example: https://bugs.launchpad.net/mvhub/+bug/394833 We usually have somebody with a little more experience who can share a keyboard with the new volunteer for 25% to 75% of the time. Often we can assign two new people to the same problem. IMPROVED STRUCTURES Right now, we usually don't evaluate volunteers performance or learning until potential employers call to check a references. (We do constantly review & evaluate code) We don't make any serious effort to keep to the milestones we've set. Projects are often selected and defined based on whatever is floating on top of our stream of consciousness with the primary selection criteria being appropriateness for beginners. Learning is "just in time" and ad hoc and closer to tutoring than instruction. We avoid the difficulty of installing our code by creating a tidy development environment on our servers. Our current approach has the big advantage of creating a relaxed, cooperative atmosphere focused on doing good, slow work rather than quick, sloppy work. Because we depend on pairing experienced and inexperienced programmers, we are bottlenecked by our limited supply of experienced programmers. Because our documentation and training is often "just in time" and our code is easily run only on our servers, it is difficult for people outside Lowell Massachusetts to contribute to our efforts. While a relaxed atmosphere helps learning, potential funders our software seem to prefer well defined deliverables and a well defined time-line for delivering them. To address these difficulties, we intend to improve our training materials for the tools and libraries we use beyond Perl itself, improve the packaging and installation of our software and work harder on feature definitions, time-lines & milestones. BROADER GOAL / PARALLEL HABITAT FOR HUMANITY The public perception is that Habitat for Humanity's uses unskilled volunteer labor to build simple decent houses for less than the cost of paid professional labor. From my 7 years working in the IT dept of Habitat for Humanity International and continued involvement as a volunteer at the local level, I know this is not the case. Dividing the amount of money raised by the number of houses built, Habitat's amateur builders at best accomplish the same cost efficiency as professional builders. Unskilled volunteer labor is unpaid, but requires either re-work or behind the scenes staging and setup. These costs don't go away for being hidden. This does not mean that Habitat for Humanity has failed, their goal is to make simple decent housing a matter of conscience. The important part of building houses is the effect it has on the builders. Making useful and reliable FOSS is our short term goal. However our long term goal is to help change world culture to include the free software values of transparency, meritocracy and generosity. We can't make our long term contribution by telling people to be more transparent, generous and fair. We can only offer people the chance to indirectly develop these values by their volunteer effort.