Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I enjoy going to hackathons as it gives numerous benefits (like free pizza), but I have never successfully navigated the projects through to a good ending. Most hackathons in my area are approximately 8 hours of actual coding.

What is the best way to manage a project in such a short time period? From creating the idea to some sort of semi-working product. In such a short time, should a project have one feature and if it gets done, another feature can be started? Should everyone work on the same feature? How should leadership be formed? Should there be leadership or direct democracy?

It always seems that either the scope of the project is too much, or major time will be lost on solving some sort of problem.

share|improve this question
4  
If you knew the answer to that, almost every software industry would pay good money to get that secret out of you. That's the heart of the problem with groups of programmers: planning and communication. –  Neil Apr 19 '12 at 14:15
4  
So, free pizza counts as a benefit these days? It seems global economy has hit a new low :) –  Jas Apr 19 '12 at 20:15
add comment

3 Answers

up vote 3 down vote accepted

In such a short time, should a project have one feature and if it gets done, another feature can be started?

Yes and no. Yes if one feature depends on another. No if the team you are working with knows what they are doing, you have worked together before, and you have worked out leadership.

How should leadership be formed? Should there be leadership or direct democracy?

The leader should be obvious to you immediately when you find out who your team is. A leader has the following traits:

  • If forced to, he could do the entire project himself or with minimal help. This way, he could help others and still be writing his own code.
  • He is respected. Nobody is going to listen to a sorry programmer who is a jerk and doesn't pull his own weight.
  • He's not afraid to ask questions. Even though he's the guy in charge, he can still ask for help... just not too much.

Should everyone work on the same feature?

You said it yourself. There is minimal time to write all of the code. Depending on the size of your team, you could have two people on one feature, but split it up and get things done.

share|improve this answer
add comment

These tips are based on a competition, but I think it applies in non-competitive events too.

I participated an event like this last year and wonned in my category. In that event, there are some technology men from various companies giving us tips. Some tips from my them and my experience in this events are:

  • do it with fastest way: If you are fast with patterns, use patterns, if not is, not use.
  • focus on main functionality: don't waste your time with functionalities that don't aggregate much to the program.
  • only add necessary validations.
  • if you present the software, train before to not enter in broken areas.
  • don't lose your time with technical details (in that competition we was coding database save, read, etc), but a mentor told us that was unnecessary.
  • another example of this can be using Facebook comments instead of building a comment system.
  • know the judges and what they expect.
  • use modern concepts that add value (today this can be social network integration or mobile usage, as example).
  • don't lose time with discussions: the team decides what do.
  • FOCUS ON ONE MAIN FEATURE!!!
  • NICE INTERFACE!!!

If will follow these tips, at the end of day (or night), you will have a cool prototype that is the maximum you can get in some hours.

In this page (translated by Google Tradutor because content is in portuguese), there are comments of business men about the projects in the competition I've participated. I think this can be useful to see what they expect and so, adding constraints to the hackatons you attend.

share|improve this answer
add comment

I can't answer this based on experience but its seems to me that the right approach to this is to pick from the big book of "agile" (certainly this is the approach I would take).

To take the two most obvious points

Do you need a leader

No, but you do need a product owner - someone who defines/champions the requirement. Beyond that the team needs to self-organise (though that might throw up a leader by default). There is an issue with where the buck stops (who decides) but practically you don't have time...

should a project have one feature

Yes, absolutely, you're working towards the minimum useable functionality - that's your first objective. Once you have minimum useable then you can add more - that might be an additional feature or it might be an improved UX for the feature you've already got.

To come back to organisation - do the things you'd want to do anyway, create a backlog of stories, prioritise them, queue them up, work through them in order (I appreciate there will be dependencies). What you want is a kanban style approach - limit your work in progress to the size of the team (and according to skills available) and let the stuff flow from left to right. Sticky notes arriving in the "done" column will help the stress levels.

If the team is large enough I think there's a strong case for pair-programming here - the aim being to reduce bugs by having two pairs of eyes on it from the off. At the very least try for quick and dirty code reviews early and often.

I know its a "hack", I know that that's supposed to mean "quick and dirty" but applying a good practice from the off should pay back towards the end of the day and regardless of where you end up you'll have something that shows that you made an effort (photograph your board (-:)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.