Is Harry Fairhead being serious when he says that Hackathons are dangerous? Does he really want to see the zen put back into code? What exactly is the objection to being cool?
Hackathons are an ever growing phenomena and not just in software.
What is a hackathon?
In principle it is where a group of enthusiastic software or hardware people get together to create something usually in a fixed, far too inadequate time frame.
It sounds great doesn't it?
What could be nicer or more positive than generating a community spirit of endeavor and what could be better for programming and technology in general. We need fresh blood and if hackathons bring in the kids.Who am I to put a damper on the whole idea?
There has long been a split in the identity of software developers. You can think of it as two competing archetypes.
The first is the serious study of software, typified by computer science, working alone and often working late into the night. This archetype is in itself a spectrum ranging from the mathematical computer scientist and software engineer to the socially inept loner working on something no one understands until is it released into the world - if it ever is.
This archetype is distinctly uncool because it is the product of silent isolated study and often, but not always deep thoughts about logic, design, code and more...
In many ways, like it or not, this archetype is close to what we really do - be it in hardware or software. Despite what the extreme programmers will tell you, programming is not really a collaborative enterprise and you can see this is true from the lengths we have to go to in an effort to make it so. At best we can work as a team on a project by breaking it down into self contained chunks that each programmer goes off and works on alone and isolated - until they check in their code and find it brings down the entire system.
And don't mention pair programming as an example of collaboration - it just isn't. So you think that one guy sitting creating code while the other perches on a chair commenting on how it should be done is collaboration. If so you really have been out of polite society for far too long! Pair programming is an example of the "actor-critic" paradigm from AI. The actor is the programmer typing in the code and the critic is the passive observer providing course corrections as part of a feedback loop.
Let's get this clear once and for all - programming is an isolated sort of activity best suited to people who can work on their own.
This brings us to the hackathon and the second archetype.
It just isn't cool to be isolated and working on something so intently that the world just passes you by. So what we need is the rock star programmer or programming as jazz. We need an archetype based on the good looking guy or gal who does nothing by way of study or preparation but just does it. They come up with the goods even when the first archetypes have spent years studying the subject and working on the code for years. They walk in, throw down a few comments, type a few lines and its all fixed and the app does not only what it was supposed to (I won't go into the subject of requirements management) and much more.
Well it works in the movies and the hackathon promotes the same hyperactive approach to problem solving. It is over-hyped and never pauses for a moment to draw breath and consider the problem and how to tackle it.
Programming as jazz, i.e. free form composition, is just as silly but very seductive. After all it is our chance to look not just socially acceptable, but cool. The whole idea is seen at its most amazing when applied to hardware.
At a hardware hackathon people put electronics together like it involved components that don't blow up in a smelly sort of way if you get it wrong. Circuit calculations - who needs those?!
Yes there is a certain amount of jealousy here - I only have to look at an electronic component for it to fail. But, jealousy aside, this just isn't how electronics is done in the real world, not even the real world of hacking.
Washington Square News
The same objections apply to software construction, but without the obvious burning smells. Throwing together a piece of code that half-implements something isn't true to the real world. It also hides the well known fact that 90% of the effort in building any software is needed in the last 10% of the implementation - which at a hackathon is usually left for another day.
We also have the fact that many hackathons are commercial. It is an attempt to get some free work done in return for some pizza and perhaps a prize. This free work aspect is also true of many software competitions, but hackathons somehow manage to cover up the commercial side more successfully.
Hackathons are about getting something to work without detailed planning and with no documentation, fuelled by hyperactivity, sleep deprivation and junk food.
What are we to do?
In this case you are damned if you do and boring if you don't.
The problem is very general. Science, and chemistry in particular, have been made to seem sterile - mostly because of health and safety considerations. In an effort to make it all seem sexy we now have scientists dumbing things down with street science and TV shows creating the atmosphere of a "science-athon". Science as entertainment might just manage to sell the subject enough so that when the victim discovers what it is really all about they aren't too unhappy.
But computing? What are the poor duped fools who were led to believe that computing was somehow social and fun going to do when they realize that it actually involves communing with a screen rather than people?
Are we in danger of inventing a whole generation of hyperactive, out of control, programmers who can't sit still long enough to complete a procedure call?
I agree that we do need to make programming and computing in general seem exciting, but sometimes we go too far and the hype obscures, not heightens, the excitement and pleasure. It might be time to start a new reaction to the hyperactive, hype-laden hackathon and promote zen in the art of programming.
Version 1 of RStudio, the IDE for R, is now officially released. The new version, which is the 10th major release since its initial launch in 2011, has integrated support for the sparklyR package and [ ... ]