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?
I'm sure many more people would have a cleaner house if cleaning their house was fun.
Why "faster velocity of development"? Wouldn't "faster development" have worked?
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.
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.
A project generally regarded as pointless will likely have a difficult time finding contributors that sees this kind of fun in it.
sounds like an interesting methodology - but what does FUN stand for? How does it compare with SCRUM and is it Agile?
How can we teach this as a thriving Software Engineering methodology if it doesn't have a silly acronym
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
i agree that python has a tendency (at least for me) to cause relaxation and make even otherwise boring tasks fun due to its extremely readable nature and good balance of write-once vs. read-often.
I think you underestimate the ability of people to write bad code -- I've seen a great deal of really crappy impossible-to-understand python code.
I get the impression that many people think "hey it's an easy-going casual high-level language, I don't need to use any care whatsoever!"
[This problem can be even worse with languages that have an "easy" reputation and are less naturally clean than python, e.g., perl, or (shudder!) tcl.]
We live, as we dream -- alone....
Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it. The idea is to give far more people the ability to fix that problem (a number which is proportional to the number of people who are likely to cause the problem, so the problems shouldn't get out of hand).
Why is the software problem more serious? Because softare is fragile. Is that inherent to software, or is it just the condition of the software development tools and processes we use today? I believe it is the latter. I believe software development tools and processes could be a lot more robust and forgiving of simple mistakes. And if projects started really opening up contributions, made it as easy as editing a Wiki, then they would be forced to become more robust. This is a good thing, not something to be avoided.
I'm not sure the conclusions from The Mythical Man Month apply directly here. The main conclusion is that adding developers to a project makes it take longer. Open source software isn't on a strict schedule, and it doesn't have central management with clearly defined lists of requirements. New contributors aren't assigned to speed up existing work, they add their own features and improve the software in their own way.
Most successful open-source projects also have exactly one author. Massive parallelization works best for something like Wikipedia that's both big and inherently parallelizable. Most software isn't like that.
I'm thinking about the big projects here. KDE, GNOME, Mozilla, Debian, etc. But why is it that developing software isn't inherently parallelizable? To the extent that is actually true, once again I blame the tools. We need better software development tools to make software development more parallelizable. I don't think there's any inherent reason why "Joe's Yet Another MP3 Database" on SourceForge shouldn't be able to use this type of develoment methodology, given the right tools.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
No, it's more serious because, e.g.:
- People depend on software to get their work done.
- Broken software can mess up your data.
- Malicious software can do bad things, like give your credit card number to Russian gangsters.
Vandalizing a Wikipedia article has none of these serious consequences.Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it.
If you take the total number of people in the world who are interested in and capable of doing OSS programming, and divide by the number of OSS projects, the result is a number close to 1. This is why most OSS projects have a single author. Imagining that "only a couple of people" have the privileges to fix a bug is actually optimistic -- the most likely case is that only one person is interested.
Find free books.
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.
Sure, if you want an uglier, single paradigm language that's harder to maintain, it's great. But us non-zealots prefer to use languages that are easier to read and don't think that a single programming paradigm is the end-all and be-all.
The "lines of code" argument is tired, old and bullshit, frankly. Anyone can write a minimal line version of practically anything, but that says nothing for maintainability, readinability or anything else. Someone's written a 3 line RSA utility in perl, but have you taken a look at it?