tl;dr? Like the Boy Scouts: Be Prepared

be_preparedThe Nerdery’s Overnight Website Challenge is coming up again. I will be participating for my 5th year. I’ve had some good years and some bad. I’ve used software that I love and software that I’ve hated. I’ve been on teams that were finalists, one that won the event, and others that weren’t close to the podium but had a great time.

By now, I think most of the webchallenge web pros are seasoned veterans, but none-the-less I’d like to share some of my pro tips – if only for self-documentation. You should first take care of yourself before, during, and after the event. But when it comes to your team, the short story is: Be Prepared. The long story? Do as much as you can ahead of time, not the day of the event.


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.



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.


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.

13 thoughts on “Overnight Website Challenge: Be Prepared

    • Derek, I really wish everyone could have read Andy’s blog… then it would be more apparent that my statements were tongue-in-cheek. I just picked two teams that revealed their technology base in their names to poke fun of (but sarcastically) in a similar manner. Degrading isn’t it?

      I use too many Ruby tools on a day-to-day basis to be able to actually insult Ruby or it’s users.

      • Sarcasm noted! Ultimately I feel the team dynamics matter more than the tools (as you allude to in this post), especially for the scope of the event. Unless of course one of the (3) Ruby teams win, than it was because of Ruby and Ruby is awesome.


    • The statement goes for the technology as well as the personnel… I found myself on a team where I was good friends with the captain, but our technology lead was not only a curmudgeon, he was the only one proficient in the software he had chosen for the team. It made for a frustratingly long night.

      I’m just saying I’ve found my home with FullCourtPress, and if anyone else has found their team or technology frustrating, they should branch out.

  1. Well, if Ruby.MN programmers are hippies, then WordPress programmers must be “Grand Masters of the Obvious”. Thanks for such insightful information as “you should use version control”… I will treasure your nuggets of wisdom forever.

    p.s. 🙂

    • I didn’t say Ruby.MN programmers are hippies, I said all Ruby programmers are hippies! 😎

      You’d be surprised how many designers arms I’ve had to twist over the years to convince them that using version control will not slow them down. Overwriting each other’s CSS files will (and did) slow things down.


Leave a Reply