Slashdot Mirror
Optimizing Development For Fun
chromatic writes "Geoff Broadwell has written an analysis of optimizing an open source project for fun, specifically the Pugs project. Broadwell argues that making development fun and easy leads to higher quality code and a faster velocity of development, even when implementing a frivolous project (a toy Perl 6 interpreter) in an uncommon language (Haskell). The Pugs leader, Autrijus Tang, will speak about both Pugs and Haskell at EuroOSCON."
But, as a programmer, if the project I'm working on isn't something I want to do, and enjoy doing, why am I doing it? Even in the workplace, all of my projects are fun to me - That's why I decided to work there! And as open source projects are generally done as an aside, why volunteer to work their if the project doesn't interest you anyway? If you're not enjoying what you're doing, why are you doing it?
Every project has a set of goals that guide it through the meandering path of development. For some projects, these goals are unspoken, seen only in the primary style of the code, or in the size and shape of its APIs. When Autrijus Tang started the Pugs project to create a Perl 6 compiler, he had an explicit goal: optimize for fun. Fondly referred to as -Ofun -- a typical compiler writer's joke, referring to the standard -O flag used to tell a compiler what its primary optimization goal should be -- optimizing for fun is probably the most important decision Autrijus made. Optimizing for fun has had tremendous benefits. In just 8 months, the Pugs project has gained well over 100 committers, averaging about 30 commits a day for the life of the project. Unlike many projects, these commits do not all come from a handful of people. In fact, the 3 busiest developers can only claim about half the commits; the rest are well spread, with 50% of the developers able to claim 9 or more, 25% having 24 or more, and 10% having over 150 commits each! The team is not just productive, it's also creative. Starting with just a single interpreted backend written in Haskell, Pugs has added compiled backends for JavaScript, Parrot, and Perl 5. Dozens of modules have been written or ported, ranging from encryption algorithms to IRC bots. Various developers have experimented with concepts ranging from continuations and coroutines to self-referential preludes and efficient type inferrence, with working code often leading the official specs. Of course, this should come as no surprise. As any cognitive science expert will tell you, fun is a great way to focus the mind. Developers that aren't enjoying themselves will slow down, write buggy code, make poor decisions, and eventually leave the project (even one that pays). Conversely, rampant fun will bring coders in droves, and give them a passion for their work that shows in quality, quantity, and goodwill. It's a pretty good bet that optimizing for fun will produce a better product than almost any other method. So what's Autrijus's secret for -Ofun? As he puts it, "the essence of fun boils down to instant gratification and a sense of wonder and discovery." Or as chromatic calls it, imagineering. It turns out there's quite a bit that goes into that: * Make -Ofun your primary goal (there can be only one). Next time you're forced to come up with a vision or mission statement, try that one on for size. (If management agrees, you've chosen a good place to work.) Every other goal chosen for the project should either flow from that one, or be secondary to it. * Use modern, decentralized version control. If you're not already using a version control system, shame on you. If you are still using an old system such as CVS, RCS, or SourceSafe, you're really missing out. Modern systems offer atomic changesets (so all edits relating to a single conceptual change can be captured together), full versioning of directories and symbolic links (so that files can be moved, copied, or renamed and still maintain full history), fast tags and branches, and more. Most important, modern version control systems offer decentralized, offline operation. Every developer can keep a local copy of the repository on their laptop, editing and committing locally to their heart's content, even when network access is unavailable. When ready for a merge, the developer can push changes to other developers or to a central "master" repository. Some systems, such as darcs and the git family are decentralized at their core; the excellent SVK client layers decentralization on top of a modern centralized system, Subversion. * Embrace anarchy. One of the key realizations of modern Internet projects (the oft-quoted Web 2.0) is that on the whole, your users can be trusted. The key is that the users also need to have the tools needed to repair any damage the tiny minority may cause. For a development project, modern version control systems can give you "anarchy with an audit trail". If something does go wrong (intentionally or more l
Use Python!
Seriously - we use it except in a few places where C/C++ is a better fit for interfacing with DirectX. The results? People are having real fun and getting a ton done. We couldn't be happier.
I'm sure many more people would have a cleaner house if cleaning their house was fun.
I am very enthusiastic about this kind of collaboration, the wild "everything goes" approach is very appealing as it invites anyone to do anything since "breaking something doesn't matter because it can be fixed in a few keystrokes".
However, my personal experience is that there will at some point arise conflicts, arguments and general disagreements, often leading to one or more developers to just pack up and leave. Or worse, fork!
Anyone else had any experience with this very loose development collaboration model?
while optimizing projects for maximum fun is great, it doesn't actually increase productivity unless the project itself is a productive project. i'd rather have a slow project than a fast one that's end result is useless.
I've used Haskell before in a college class. Nothing too "fun" about it, though its recursiveness could be usefull in some applicaitons.
Why "faster velocity of development"? Wouldn't "faster development" have worked?
Things to Avoid: The Haskell Wiki
why the Perl 6 term doesn't write a production-quality Perl 6 interpreter before they branch out into frivolous projects.
Or maybe the whole Perl 6 project is a Manchurian Candidate to ensure that Python and Ruby finish draining the Perl community like starving vampires.
At any rate, it's ironic that Perl, a language once known for appealing to hardcore pragmatists, is in its 6th iteration becoming an increasingly irrelevant theoretical playground.
What motivates a programmer to spend time on open source projects ? Certainly the spirit.
Extreme Programming - OSS style.
Embrace anarchy
It's important also to make committer sign-up fast and easy
new committers could be invited en masse and sign up on their own
committing quick and dirty protypes that can be refactored as they grow
;-)
*AAAHHHH*
and i thought (quick and dirty) prototypes were supposed to be immediately scrapped and their essence implemented in clean, revised code... *silly me*
all in all an interesting read, commending "anarchy" and as-turbulent-as-possible commits over more stringent methodologies. i can imagine that PUGS is going along quite "smoothly" and am in awe how these two radically different communities (haskell and perl) managed to find each other
but whether this community and flair can be reproduced simply by adhering to somewhat questionable guidelines is another question alltogether.
this to be implemented into apt-get so we the debian community are still superior to those pompous fun-compiling gentoo users.
IMHO this philosophy could go a *lot* farther too. We should be building these types of concepts into our software development tools (not just source control but IDEs and compilers and even languages). It should be as easy as possible for users to get the source, build it, modify it, and submit their changes. Ideally as easy as editing a Wiki. Though the inherent complexity of software means that Wiki simplicity will probably never be reached, we could certainly do a *lot* better than we do now.
In an open source project the ease of the process of getting, compiling, modifying, and submitting changes to the source is directly related to the number of new contributors joining the project, which is directly related to the rate of improvement. Traditional software development tools have far too many pitfalls and require far too much know-how for casual users. The process of contributing to open-source projects could and should be a lot more automatic and foolproof, because attracting contributors is the single most important thing an open source project can do to improve itself.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
This all boils down to one thing: Open the CVS access for everybody. And that is exactly what I have come to hate about the GNOME project: Development is essentially closed because every piece of code needs to be reviewed and there are not enough reviewers. I often wondered whether these guys really believe in Open Source. Is KDE development equally restrictive and boring?
What a weird article description. Getting people to hack on frivolous projects generally isn't a problem. Getting them to hack on tough projects can be. Okay, maybe this is a test implementation in a funky language, but this isn't a frivolous project according to the Perl folks; Damian Conway described the work as "both amazing and amazingly useful: as a way ofe /19263
exploring the deeper design and implementation issues" here:
http://www.nntp.perl.org/group/perl.perl6.languag
Worst of all, the word frivolous distracts from the point of the article, which is all about techniques you can use to help making hacking on any project fun. It's not about only hacking on projects that are instrinsically fun, as 'frivolous toys' tend to be.
projects some of us have to work on. I *do* enjoy programming very much, but I also get stuck in boring stuff waay too often. And yes, I need to put food on the table for me, wife and 2 kids.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Ahem, I think they missed a letter out of my name...
"specifically the Puggs project."
Just had to clear that one up
To further the idea a little more, the wiki also helps in documenting the structure of the project, and like other tools would be able to show any/all references to given code.
Certainly, if you're a hardcore coder, you'll have a preference for direct access to the cvs. For more casual coders, or those who just want to wander around looking for interesting things to help on, the wiki frontend could help.
That being said, I have no idea how well this idea could work, but for smaller prototyping projects it might just work.
...makes the -- aw, fuckit.
I do unpleasant programming as a cover, while I and others like me hunt down people like you and beat the crap out of you. Keep your bliss to youself you hippy!
no one should be having fun at work. that's why it's called work. that's why we hire you to do it for us.
The release tarball will be available from CPAN shortly:
With two months of development, this release features more tightly integrated JavaScript and Perl5 code generator backends, a library interface to the Pugs system via support for the Haskell Cabal frameworks, as well as many new tests.
After the release, the push toward 6.28.0 will begin in earnest, with the newly specified container model and object model integrated back to the main runtime, fleshing out support for the remaining OO features.
Again, thanks to all the lambdacamels for building this new ship with me. :)
Enjoy!
/Autrijus/
Changes for 6.2.10 (r7520) - Oct 10, 2005
Feature Changes
Shared components
JavaScript backend
Perl 5 backend
My brother-in-law needs to tell O'Reilly to update his bio, since the birth of my nephew (his son) some few months ago...
I am the Lorvax, I speak for the machines.
That shouldn't be called "Avoid Recusion," because you're not really avoiding recursion. What you're doing (as the wiki itself explains) is abstracting it into a higher-order function. Still a pretty damn important technique that one should master in functional languages--recognizing the "shape" of a loop (is it a map? a left or right fold? an unfold?), and implementing the looping logic as a higher-order function separately from its specific uses.
Are you adequate?
nicht GNOME - stupidprogrammerfunken
Thanks Autrijus for leading by example and making the Perl6 process thoroughly enjoyable. These qualities have never existed in the Perl6 or Parrot projects prior to your arrival. The experience and enthusiasm you have is a very welcome change.
if it wasn't for my Mom's attitude towards us doing it.
If you take the attitude that it's okay to stop without holding everything to a nebulous standard of clean, it becomes easier.
The article was about optimizing development, not optimizing code.
Badass Resumes
Anybody else read the headline and assumed the article was about someone having fun doing development optimization? No? Just me, then? OK, never mind...
Because there are 2 kinds of fun/joy systems in the brain.
The kind triggered by dopamine, the short high that doesn't last, the Mtv, nicotine, "I want to buy this" kind of fun.
And the relaxed kind of contented joy that works with the serotonin system in the brain. Which does last and is an indicator of good relationships with friends, experiencing nature and knowing that "all is right in my domain, I'm ok for exploration into new things" kind of fun.
That last kind of joy is an indicator of efficiency and "everything is as it should be" and if you feel that while coding, you must be on the right track.
- -- Truth addict for life.
Tcl (and Tk) is still hanging in there, chugging along. Some recent developments:
Tile: modern look and feel + themes for Tk: http://tktable.sourceforge.net/tile/
An object system for the core: http://www.tcl.tk/cgi-bin/tct/tip/257.html
I think the other big thing that's still missing is to make the standard distribution 'batteries included' - we'll see if we can make that happen soon.
I love the language, in any case, it's super easy to get people started with, and if you look under the hood, it's coded very well, and has an *extensive* C API. That was what really sold me on the language - the ability to really integrate it well and easily with C code. Python's C API is good too, but I thik Tcl's is still broader.
http://www.welton.it/davidw/
Calling Pugs 'frivolous' and a 'toy' project is like calling linux frivolous, and a toy OS. The fact that Pugs seems to be fun to write, and seemed like something that they writers would like building, has little to do with it being usefull, but does illustrate one of the reasons that a lot of free software is good -- it was fun to write.
Using Haskell is also something that only improves the fun, instead of what the 'even when' implies. Partly, perhaps, because it is a bit uncommon -- because it is fun to learn something new -- but mostly simply because it's Haskell. I did some numerical maths-practical assignments in Haskell, while others used C or Pascal (the choice of language was free). My programs where invariably about 10 to 25% of the length of most others, while being a lot more readable and easier to write. Haskell is actually a lot of fun to use.
Jan
Dude, learn to use enter. Make some paragraphs. Maybe add in some structure. Is that the entire article? WTF? Why did you waste our time with that post? Why did I waste my time writing this? Anyway, if you mod the parent down, my post won't be read, so don't bother modding me. I like my karma. And marijuana. And alcohol. Obviously. Heh heh.
Windows XP for example. Both fun and useful. What did you say? No source code? Come on , not a problem for a real programmer.
In my blog entry Disorganized Incremental Software Development, I describe an idea for a programming language where all implementations and specifications are named using cryptographic hash codes of their contents. This avoids all name collisions, and means that you can let anyone be a "committer", and indeed dispense with version control altogether (except for comments, which still have to be written by someone who knows what they are writing).
Music: a super-stimulus for the perception of musicality. Musicality: a perceived aspect of speech.
What I've found though, is that if you go into the work place with some 'higher-order order' in mind, and try to unify everything you do into one clean infrastructure, the fun does linger. You should have a greater vision to which all other projects must conform. Yes, you do still have to write boring bits of code but there is a nicer feeling all around, together with a drop of professional pride on every line written. This over-all vision has taken many guises - clean code trees, re-use, falling into a meaningful code hierarchy, writing code which is more service driven. As you advance, your higher level vision also grows. With it, you'll find greater professional pride, better code, more arguments with management and a bigger head. Primitive and closed minded environments can be a hinderance, but you have to persist. I do agree though - if you can keep the 'fun' alive, it does result in better code. What we shouldn't forget is that it's not 'all fun, all of the time.'
While writing perl in haskell *is* fun, writing haskell in perl would be a horrific nightmare torture. Perhaps all code language disputations/wars should be solved by duel of this kind.
There you are, staring at me again.
1. Use the "Plain Old Text" setting.
2. Preview your post.
This stuff should be second-nature to anyone with a UID of less than 300000 or so. Shame on you!
The article was about optimizing development, not optimizing code.
You've obviously mistaken me for someone who actually read the article. Anyway, I don't see any difference between the two.
"You'll get nothing, and you'll like it!"
on why chromatic considers a perl6 interpreter "a frivolous project".
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Definitions of frivolous on the Web:
* not serious in content or attitude or behavior; "a frivolous novel"; "a frivolous remark"; "a frivolous young woman"
wordnet.princeton.edu/perl/webwn
Related phrases: list of frivolous parties frivolous complaint frivolous lawsuits frivolous lawsuit frivolous suit
That's the question: I even resent calling pugs "a toy Perl6 interpreter". I think it's a serious project, optimized for the fun of its committers. And watchers, like me. But it works a lot and it's teaching me a lot of stuff I didn't know. Being fun is not the opposite of being serious, that is to say, being fun is not the same of being frivolous.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Cool. My original post gets modded off-topic and my reply to a reply gets modded troll. Woohoo!
"You'll get nothing, and you'll like it!"