Goals

This is sort of an esoteric concept, but very important none-the-less. Your non-profit is going to come to the event with some goals in mind. Your team should have some goals in mind as well, and with any luck, the overlap will be pretty good.

Some team goals:

If there are programming customizations outside the realm of “out-of-the-box” solutions, limit large custom programming undertakings to just one (1). You’re better off having one killer feature or integration point than two that partially function. Custom programming stuff is inevitable because your non-profit probably uses some CRM (Client Relationship Manager) that no one has ever heard of. Be aware that if you send two members of your team down a rabbit hole on a task like this, you may not see them until the next morning. Don’t count on this task being done. In fact you may want to mitigate the feature set so that it works “good enough” for the presentation / demonstration. Know what will cause the feature to “blow up” – and don’t do those things during your demo!

Launch a new site at the end of 24hrs. This seems obvious, but it really requires restraint on both the web team and non-profit’s behalf. Too often, one or both sides gets caught up in certain feature or aspect of the site that prevents the site from launching at the end of the contest. Be willing to accept that the site may not be 100% feature or content complete, and instead relish the fact that the baseline product now looks and acts as a solid foundation for the future.

Hardware

Server

This is the base of everything everyone on your team will be working with. Whether it is a hosted server in a data center, or a laptop that you bring to the challenge, have it set up for everyone on your team.

I would like to warn teams in advance not to count on whatever in-kind hosting has been donated to the event. In the past, this is VISI. VISI used to be the bee’s knees back in 1999 when they had the best DSL service in town. VISI had been bought and sold so many times since then, I’m not sure what was left from the original.  Needless to say, their hosting left something to be desired.  I don’t know how well ipHouse will be meeting the need. But don’t be surprised if your donated virtual private server is CentOS5 with 256mb of RAM and PHP 5.1.6 installed with no clear upgrade path.  It may be no better for Ruby, Python, and .NET environments.

Your non-profit may have a host that they already like and is usable. However you can’t count on that so you should always have a Plan B (or Plan C). If someone on your team has a host where they can easily create a new web-root for development and testing, you should have it prepared and at the ready.

OpenWrt + Dnsmasq

This has been sort of a “secret sauce” for our team. Our server is on a laptop local to our team. We use an OpenWrt router with Dnsmasq that everyone on the team connects to. No one has to create host entries to connect to the laptop/server and it’s consistent for everyone. At the end of the competition, we simply give our presentation from our laptop/server since we can take it anywhere.

Software

Are you using a CMS? My team uses WordPress, so we like to come prepared with every plugin and theme pre-installed that we’d normally recommend for any client. Deleting unused extras at the end only takes about 5 minutes.

Version Control

Some people still feel that using version control is going to slow their team down. You’re doing it wrong – which probably means you’re doing it wrong at your day job. Do everyone a favor and learn the concepts of version control and have your team all agree to which you’ll use. Subversion or Git are both fine choices. We will be using Git as GitHub – they’ve been an event sponsor in the past (plus Git is pretty rad).

For those who you may have to drag kicking-and-screaming into the world of version control, you can set up a network share on your server where all changes are automatically committed. This may take up more setup time than it’s worth, so I instead recommend teaching your team to fish with whatever tool(s) everyone agreed upon.

Great kid, don’t get cocky!

There’s one last thing I want to address is about winning. I’ve done it. I did it on a team where I didn’t like our technical leader nor the software he had chosen for the team (thanks for asking!). This would make any developer unhappy. In short, it was not fun.

This blog post from the 2011 contest has some good tips from a winning team (and some bad), you’ll have to view the cached version here: Andy Blogs It – look for How we won the Overnight Website Challenge -or- How you can win next year. Much of the last 1/3rd should be ignored in regards to technology choices and especially in regards to technology opinions.  Go ahead, read it.  I’ll wait. Being of infinite wisdom, Andy’s blog was on Posterous and is no longer available.  I’ll give you the cliffs notes: he gives a bunch of good tips at the beginning and then proceeds to diss PHP and WordPress amongst other things.

Would I go and publicly insult team Ruby.MN because Ruby is for hippies? No way. Am I going to try and convince the Drupal team that WordPress is better because it has bigger market share? Absolutely not. We all do what we do because it’s what we like and what we know. Similarly, if you find yourself on a team where you don’t like what you’re doing – jump ship! The Overnight Website Challenge will only bring you satisfaction if you enjoy what you’re doing.