3 replies to this topic

[Shaquil]

I'm going to lead a group of programmers during a local hackathon. Well, they call it a hackathon, but since they're telling us to just build "an app," it's more of a develop-athon. Anyway, we'll be working together for 24 hours straight, and we've never worked together on a project before. I know that by now I've probably raised many red flags about our likelihood of success, but I'm trying to mitigate these problems. The event is in two weeks. We're going to do an 8-hour practice session this Sunday, and today I'm going to start making it clear that anyone on the team who thinks they might want to drop out should do it right now. I feel like the fewer people we have, the better our chances.

 

So do you guys have any tips for us on how to go at the situation? Or, more specifically, do you have any tips for me on how to manage a group of programmers? I've never led a group on a software project before, and I don't think these guys have ever been led before. Any advice would be appreciated. Thanks.

[slicer4ever]

I have done 1 coding jam in the past, last year i attended toJam(72 hours to build a game based on a particular theme).

 

here's some things i took away:

1. Make sure your entire team is able to contribute(one of our team members simply should not have been their.)

2. Do your best to have a design in mind. (and make sure every team member is clear on what you/they are doing)

3. Do not allow feature creep to affect you, be very clear on what you want to achieve before going there.(This one is incredibly important for your time-scale.)

4. Know your limits, understand what you are able to do, 24 hours is very little time, and be vocal if you have any sort of problems.

5. Don't include people that won't be able to contribute(in our project, sound was simply the last thing to get around to, and unfortunately the team member that was tasked with audio wasn't able to do anything.)

6. Be very vocal if something is not going to work, if you can tell it'll take to long to implement it, cross it off your list right their.

 

A few of these points can be taken with a grain of salt, depending on how serious you want to take this. (i.e 1 and 5 can be ignored if you just care about having a good time.)

 

Personally, I was lead programmer(but not team lead) for a team of five, we suffered from feature creep(something i should have been more vocal about, when you are 2 days in, and someone says "Hey, let's add that!", you should say "No.").  The person i was doing this with(our team lead), was too interested in entertaining everyone's ideas, and the game became too bloated to complete in our time-frame.

 

We had 2 programmers, an artist, and a sound guy, and the last guy simply should not have been their.  (He was tasked with making the levels, but wasn't able to learn the level editor he was given, and the levels suffered greatly because of this(practically ignoring some of the mechanics we had built into the game, it became just a generic platformer.)

 

Their were so many problems(and a ton of stress), that it put me off from doing anymore of these jams.

Edited by slicer4ever, 05 March 2013 - 10:34 AM.

[swiftcoder]

I haven't been to many hackathons, but I've worked on a number of high-time-pressure projects with multiple participants. Here's my 2 cents...

 

Ahead of time:

• Work with your teammates before, if at all possible. Not necessarily as a group, but you need to get a feel for each of their capabilities.
• Pick your APIs and tools ahead of time. Don't want to waste precious time learning tools/APIs.
• Make arrangements for food and drink (and figure out who is paying for it!). Preferably have non-essential personnel (i.e. boyfriends/girlfriends) to actually fetch the takeout, energy drinks, etc. (bonus points if someone is willing to cook real food).
• Make sure you have enough space to work, that the space is clean, and that all your hardware arrives on time.
• Get plenty of sleep the night before!

On the day:

• Design first: I would advise you don't start coding until your design is fleshed out (your artist can reasonably be wire framing as part of the design).
• Minimize dependencies: don't have art or music sitting around while you code. If your design is fleshed out, they should be able to be productive right away.
• Iterate, iterate: get a working skeleton up and running as soon as possible, and improve/add features to it incrementally.
• Keep it stable: as you head into the final hours, make sure to always keep a stable build. Even if it isn't 100% complete, you don't want to risk a broken app when the deadline hits.
• Polish and package: set aside the last hour for polishing, packaging, testing and writing maybe even writing a read me.

Bonus points:

• Have your team all learn a version control system, and use it to collaborate and track changes. Even if you are just using it as a non-destructive undo system, it'll be worth its weight in gold. Something like CVS or SVN might be sufficient for a small team, but I'd suggest git, as it's simpler and more robust.

[tstrimple]

While not advice on managing developers exactly... I do have some advice on winning hackathons. Having been to a number of hackathons in the last year, I recommend:

 

1. Have a strong understanding of the judging criteria.

        Hackathons are different and have different objectives. Some are to create something akin to a mini-startup where they want to see customer development done as well as some market research. Fewer are pure technical build cool shit. It's very important to know which you're going to as the strategy for each should be different.

 

2. Cyber stalk the judges. 

    If they are investors, what sort of things have they invested in? If they run a company, what does it do? See if you can find out what their hobbies are and make an app relevant to them. 

 

3. Focus on the pitch before writing any code. 

        As developers we have a tendency to want to jump right in and start hacking away at something cool, but chances are if you take that approach, you will only be demonstrating a small piece of what you've built. Instead, decide what features you need to support your pitch, and build those out first. 

 

4. Polish, polish, polish. 

        This means the technical components you will be demonstrating as well as the pitch itself. Run through your pitch multiple times, and make sure to leave yourself about a 30 second buffer. That means if you have 5 minutes to pitch, only develop a 4 minute and 30 second pitch. You will inevitably run a bit long during the live pitch and you don't want to be cut off before finishing your message. 

 

5. Have a backup plan.

        Internet connections fail. Bluetooth connections fail. If something can go wrong, it will go wrong on the stage in front of everyone. I watched a company presenting at launch yesterday crash and burn because they couldn't establish bluetooth connections for their demo in front of thousands of people. They should have faked it, and no one would have known that it wasn't actually using bluetooth connections! This also means if you build a website, you should probably be having a copy running locally to demo in case you cannot get to the internet. Same with services you rely on. Mock them up if you can.