I’m at OSCON 2008 right now, which is a great conference if you are an open-source hippie like me. I’m attending the late opening keynotes now, and Mark Shuttleworth just talked about how we need to give agile programmers a break, because even though they might write crappy code, it’s more about providing new features. See the rest after the jump.<\/p>\n
<\/p>\n
WHY AM I HERE? Oh yeah, to see this keynote: The Google Open Source Awards. Wow, does Chris Debona seem more sweaty this year than previous years? Winners include <\/p>\n
r0ml went on stage next. I like this guy. He says there’s no open source adoption methodology. The problem, he says, is that large corporations likes methodologies. For instance, the MS methodology: <\/p>\n
So companies can say "We use the Microsft Framework. How’s your project going?" It’s very important to have a graphic at this point. The rational unified process is a different model. You don’t envision, you go strait to inception. Even the Agile methodologies have a similar flow: <\/p>\n
The Open Source Ethos, according to r0ml: – Running code speaks – Peer Review – Release early, release often – Given enough eyeballs, all bugs are shallow – Community matters – Fail fast – always make new mistakes. At this point, r0ml went off on some Rhetorical Development Framework developed by Quintillian in 80 AD, and compared it to Microsft’s framework, and things went south from there. Hilarity ensued. It really helps that r0ml is speaking at nearly 10:00 PM local time. <\/p>\n
Next, he talked about juggling and how it applies to software development. And yes, r0ml juggled. It’s all about tracking problems. It’s not about "throwing what you can", it’s about "throwing what you must". That, he says, is what makes your software exceptional. The r0ml Exceptional Software Methodoligy: <\/p>\n
Some of you may notice something missing. There are no requirements. You just have bug reports. There is no development, there’s only maintenance. It’s just that some maintenance is more radical than other maintenance. * Why do we have requirements? Because we want to agree up front what we want software to do. This is a mistake. Requirements gathering: everyone decide now what you want to do, and we’ll decide later if that’s a good idea. After we release the software. – Ugh. You, as the customer, have to test the software. But that’s easy – all you have to do is complain when the software doesn’t do what you want it to do. !!! – Really? Errors are a good thing. We’re going to embrace the errors. They’re just exceptions. – EXCEPTIONS – Read that again. It’s all about EXCEPTIONS. We’re all writing EXCEPTIONAL software, right? \ud83d\ude42 – Rinse. Repeat. <\/p>\n
Perl White Camel Awards: <\/p>\n
Where the hell is Larry Wall? Some guy read from cards. WTF? I’m going to go get another beer. Someone please send me the preso. It’s probably written in powerpoint. Cripes. <\/p>\n","protected":false},"excerpt":{"rendered":"
I’m at OSCON 2008 right now, which is a great conference if you are an open-source hippie like me. I’m attending the late opening keynotes now, and Mark Shuttleworth just talked about how we need to give agile programmers a break, because even though they might write crappy code, it’s more about providing new features. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-292","post","type-post","status-publish","format-standard","hentry","category-technical"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t