First the nice list. You all deserve the best present Santa can bring.

My kids: Brandon and Lily

I’m so incredibly blessed to have my two children in my life. It’s not always easy on a day-to-day basis, but before having children, I had no idea how amazing it was going to be to watch them grow and learn and to be the recipient of their love. Nothing in life will ever compare to this experience. The two of them have made the nice list for the rest of their lives. They have made me a better person, and have brought me blessings beyond compare.

Gauged2, Authentic Jobs, and IMM

While my plans to build a long term future with two different teams, didn’t work out, I still had a fantastic time working with them this year. In the first half of the year, I had the pleasure of working with Dan Denney, Hugh Butler and Tim Robbins at Gauged2. Dan and I have since moved on to other things, but we had some really great times together and all learned a lot and grew from the experience.

I spent the last half of the year working with Cameron Moll and Adam Spooner at Authentic Jobs. We made a great team, had fun, and built an awesome product (not yet released). I’m thankful for my time with them and hope in 2013 I am blessed to work with more equally awesome people.

Also making the nice list in this category is Andy Smith (IMM). I’ve been working with him for four and a half years now doing the Miley Cyrus suite of websites. It’s been a pleasure and I hope we continue working together for years to come.

All six of them make my nice list for 2012, and to all six I say, “Thank you!”.

Apple

Say all you want about Apple holding features back to they can release improved versions, wich results in us spending a lot of the money we earn on their products. The only reason we do so is because of how fundamentally life changing their products are. Having a strong background in both Windows and Linux, once I tried a Mac, I never looked back. The combination of having Mac for your phone, tablet and desktop is unparalleled. The increase in productivity, the decrease in stress, and the pure joy in using Apple’s products earns them a spot on my nice list.

Will Muschamp

I have missed Steve Spurrier for years. Urban Meyer didn’t fill the void (see the naughty list), but finally, we have a coach who does in Muschamp. I love his personality, his style of play, his leadership and the way he handles the team. My son and I met him last year at football camp, and I’ve thoroughly enjoyed this year of Gator football. I hope he will be around for a long time, because he’s finally the coach the Gators need to move on from the Spurrier loss.

Supportive Friends

There are too many to list. Trying to list everyone would result in leaving some people out, but I have to particularly thank two people who have supported me all year in my endeavours: Dan Denney and Steve Pothoven. Listening to me bounce ideas off the wall like a racquetball player on speed, requires a special patience. They always listen, always give me their honest feedback and suggestions, and for that they earn a spot on my nice list.

To everyone else who liked, favorited, retweeted and commented on my statuses, photos and posts throughout the year, a special thank you for allowing this introvert to share his thoughts and rants with you. May you all have a Merry Christmas and a Happy New Year.

Now for the bad news with my naughty list. Shame on you.

Urban Meyer

While being thankful for the championships that Urban Meyer brought to the Gators, and also giving us Tim Tebow and those four years that will never be topped…I’ve never been a fan of Urban’s. He leads and disciplines kids with a modern day parenting and pop-psychology methodology that is sure to fail and did. Team arrest rates soared, they fought with coaches and refused to do what they were told and got away with it, and then, after allowing the team to implode out of lack of leadership and discipline, he has a mental breakdown, quits, then comes back to make things worse one last time, then quits again and goes to another school where he proceeds to tell all new recruits that the Gators have discipline issues in the locker room and poaches recruits from the Gators based on his own failures. Congrats on making the naughty list for the rest of your life. I now cheer for the Gators and anyone who plays Ohio State.

Rex Ryan, the entire Jets organization, and the majority of Jets reporters

Regardless of your belief in Tebow’s capabilities to throw a football, no one deserves to be treated like he has this year. He’s done nothing but work hard, support his teammates and run the ridiculously stupid plays called for him. Ryan and Sparano get the ‘naughty’ for having not bothered to watch a single game Tebow played in during college. That’s clear from how he’s been used. Tebow never ran the wildcat during college, and for all the talk of him being a running quarterback it was his passing that set every record in high school, SEC and college football. And yes, he set the record for…wait for it…pass completion percentage. “But he can’t throw!”. Right, because the football changed so much between college and the pros. Anyway…

Urban Meyer (his coach in college), said he had to keep Tebow out of the weight room so he didn’t bulk up and get too big and slow down. What was the first thing the Jet’s coaches made Tebow do? Put on tons of weight. He’s clearly been far slower running the ball this year. Equally stupid is continuing to judge Tebow on his practices. He’s never been a good practice player. There are numerous reasons for this, one of which is certainly his will to win that obviously is more likely to kick in when the game is on the line (much like adrelanine when your life is on the line). But there are other reasons. In practice, wearing a red contact jersey most of the time, they blow the whistle the minute any defender is in the area. I watched Tebow’s practices this year when they were available, and every time he would start to scramble and break down the defense, (where he can throw or run when he moves out of the pocket), they would blow the whistle stopping the play. Tebow’s #1 strength is ad-libbing and in practice you don’t do that. Much like training in MMA. When you are practicing a rear-naked choke, that’s all you are working on. If it fails, in practice, then you “failed”. But in a real fight you have the option to transition to other things and pull from all your tools. Judging a guy like Tebow from practice is foolish and narrow-minded.

The reporters end up on the naughty list for their obsessive coverage that turned fans and players off of Tebow. It’s not his fault he’s the focus of the team. He couldn’t be more quiet (except when forced to talk to the reporters by his coaches – also worth the naughty list). The majority of hatred aimed at Tebow should really be aimed at the reporters for causing it. They love stirring you up to hate him, and their latest trick has been blaiming the entire Jets season on Tebow. He played a play or two a game all season, but somehow it’s his fault and not the QB who face planted into his own players rear-end and turned the ball over consistently all year.

Now the reporters have gone so far as to say that Tebow “demanded” not to play the Wildcat anymore. The story has spun out of control, with none of it substantiated. We know Tebow was frustrated about being told he was #2 until #1 was benched and then he was passed over (who wouldn’t be!). We know he said something about the wildcat not working for him, and that’s all we know. Yet now, the claims are he’s “always” been a selfish player. Please, enough with the hatred. It’s far too transparent. We get it, you hate that he gets so much attention despite not having earned it in your opinion. They all seem to forget that the entire business of sports depends on entertaining the fans. They hate what Tebow did last year because the didn’t do it the way they think a QB should. It’s elitist and for that, all of you make the naughty list…to say the least. I hope you don’t represent the people of New Jersey or the entire state might make the naughty list.

The U.S. Government and the American people

First the government for bribing voters with a record-setting number of free offers, including college educations, birth control pills, health care, cell phones, housing, food, and a year and a half of pay without work. As well for buying private companies (still more bribing to win over entire groups of voters from industries) that ran their businesses into the ground. The current government, and by that I mean BOTH parties, has led this country to the brink of financial ruin, all so they can personally maintain their power over the people, and maintain their lavish lifestyles.

They make the naughty list, but so do the American voters for allowing them to do this to this once great country. Fans of football teams demand a coach be fired in his first season for failing to make the playoffs, but in government, you get re-elected (again, not talking just President here but all across the board), for taking your team to 0-16.

It’s time for voters to stop being single issue voters and start voting for people who will allow this country to return to it’s greatness. It’s also time for voters to start reading between the lines and stop listening to sound bites and voting for the guy or girl who has the best speach writers or the best web site, and focus instead of real principles and real facts.

Also making the naughty list in this category are the hypocrites who want “freedom” and want government out of their lives and then turn around and vote for a candidate promising to intrude and control at every opportunity in the name of “helping”.

Conclusion

That concludes my Naughty and Nice list for 2012. I hope you all had a great Christmas and start 2013 off with a Happy New Year!

Don’t wait to deploy until the end

I’ve seen so many teams get burned by waiting until the last minute to get the server and deploy set up. I know working on the app is why you are in the hackathon and I know that’s the most exciting, but don’t take the risk that all your hard work will count for nothing because you failed to get it deployed. Getting the server set up and working should be the very first thing you do. Make sure you have deployed, through git, to the server and see a basic Rails home page deployed and running.

Use Google Analytics and Woopra

More than anything this is for curiosity, but you’ll be thankful you did it when the judging starts. Google Analytics is great for historic reports, but nothing beats Woopra for live tracking of your users. We watched every judge come in and look around our app. We could see which ones really spent the time reviewing or apps and which ones barely looked around.

Have a link from the site back to voting

We failed to do this the first time and I think it hurt us. Many visitors may find your site directly via a share from a friend, and they may not be aware that you need votes. Having a prominent link on the home page asking for their vote with a link to the hackathon page helps communicate your situation and will get you more votes. You could consider implementing the Hello bar to accomplish this quickly.

Create a blog off-site

When the hackathon ends you can’t make any further changes to your app. This includes communicating valuable information to your potential users. I’ve seen apps that had a major bug that was preventing everyone from trying it. Though there was a way around the bug, there was no way to communicate to the users how to do it.

If you set up an offsite blog (Tumblr for example) and link to that from your site, you can publish updates and news there during the judging time without having to make modifications to your app.

The same suggestion applies to having a Facebook page and Twitter account. If you link to those from your site, you can then use all of these options to continue communicating with the users and the judges after you hit that code freeze.

Follow up with immediate bug fixes

You won’t be able to fix any problems found after the code freeze until the judging and voting is over, but that doesn’t mean you can’t have the fixes ready to go.

We fixed everything as it came up, and the minute we were cleared to update we did.

This way if your app gets any press post-hackathon, the visitors will see a more improved and bug-free version.

The experience of hacking for 48 hours can be quite a thrill, but don’t let that excitement get the better of you. It’s still important to take care of your health while hacking away, and failing to do so could leave you at less than your best.

Several studies have shown that going without sleep, even 24 hours without it, can leave you impaired in the same manor as being legally drunk. To make it worse, the first part of your brain to degrade is in the part of your brain that is most crucial to thinking. You can read more about that online, for example here.

Be sure to get some sleep during the hackathon. I recommend 6 hours each night. Doing so will help you be far more efficient during the other 36 hours you are hacking. Better to lose 12 hours to sleep, than operating at half capacity for the last 36 hours.

If you need energy during the hackathon, don’t eat sugar. Sugar will sap you of all your energy once its quickly burned in your bloodstream. Since you’ll be sitting most of the time, you won’t need many carbs at all. Be sure to eat a high protein diet and drink enough water. If you need a special lift, I recommend the sugar free Monster drinks. I drink the Lo-carb and the Tea+Lemonade several times a week. Both give me a noticeable lift in energy but never result in the lethargic “crash” typically associated with spikes in energy because they contain little to no sugar.

If you need to take a break, do so. A focused mind at 100% is better than one at 70%. During our last Rumble I reached a point where my brain was in a state that simply could not continue processing anything. Thankfully I was able to take a break with my teammate to the nearby mall (where we had strategically positioned ourselves in a hotel room we rented for the Rumble) and simply walk around the mall to get out, and get clear. By the time I returned I was refocused and ready to go.

If you want your brain to function on all cylinders like a finely tuned race car, proper care and fuel is required!

When it comes to planning out a hackathon, I plan it almost exactly as I do any app (when I work in a situation where I’m allowed to that is).

What does it need to do?

I start by summarizing into a sentence or two, what the goal of the app is. This is your ‘elevator pitch’ and will help you stay focused as you transition from big picture to planning out the details.

Next, make a list of what the app needs to do, sometimes in terms of use cases, stories, or simply a list of features. However you like to word it, the concept is the same: describe what the user will both need to do and want to do upon visiting your application’s home page.

Here are some sample use cases, the first three should probably be on everyone’s list:

• The visitor should immediately understand the goal of the site.
• The visitor should immediately get the impression that [example: the app's goal is to help children reach their goals, or whatever your app's goal is].
• The visitor should have one clear and immediate call to action they can take without thought.
• The visitor should be able to register.
• The visitor should be able to login.

Know your priorities

Once I have a list of what it will do, I put those in order from most important to least. In both a hackathon and in real life development, odds are you are going to run out of time with reaching the deadline. This priority list will probably change for a real life app, but for a hackathon and the shortened time frame, its a great recipe to stick to so you don’t have to stop and re-strategize mid-sprint to the finish. An important part of succeeding in a hackathon is the willingness to cut a feature. So many submitted apps have half-done features, or ones that were not well thought through and look hurried. Better to cut it all together and ship less, than to ship poor quality work. When it doubt, cut it, and knowing your priorities before hand can help you do this during a time crunch.

Detail the pages

To further understand the requirements of the app, I now list out every page that will be on the application, title it, describe it, and list out all the elements that will be on the page. This is great for not only ensuring you didn’t miss any tasks, but also for communicating design needs to your designer and front-end developer. I include what type of content needs to go on each page, though remember not to write any of the actual content until the hackathon begins. Also, note how the user gets to each page, and where they can go from each page. You can do this on the page notes, or even create a visual flowchart, that illustrates this.

Define tasks, roles, and milestones

Now that you know what has to be done, it’s time to break each feature or use case down into a list of what tasks are needed to create that feature, including creating the model, controller, database changes, views, design elements, etc. Then, I assign each one of these tasks to someone on the team, and note target milestones (deadlines) for each to be completed. This then helps you see if you have any chance of accomplishing your plan before the hackathon starts.

I like to group the tasks into “mini-sprints”. I find it much easier to focus on smaller groups of tasks, and its rewarding for the team when you reach each one and can hoot, holler, and high five in celebration to keep yourself on an emotional high throughout the long couple of days.

For both of our Rumbles, our first mini-sprint was the most important. We started at 9pm and the first sprint was to be completed by midnight. It was so important that I made up a music playlist just for that first sprint. Our goal for this time was to have the following completed by midnight:

• Linode server setup
• Git repo setup
• Deploy script created and tested
• Rails framework created, checked in and deployed
• Gems installed and deployed
• All models, controllers and views stubbed, checked in and deployed.

With this completed after the first 3 hours, we knew there would be no infrastructure surprises to haunt us in the end and we could focus on making the app awesome right up until the last minute.

For PeepNote, we had 11 development milestones and 6 designer milestones. We completed all 17. There was an optional list in case we had extra time, but we didn’t get to much on that list.

Plan to Fail

Another important part of the plan is to plan your failure points. Make a list of all the failure points and risks, both with building your app (the biggest challenges) and within the app (exception handling).

Some of your tasks may be technological “risks” and if you aren’t prepared they could derail the entire plan. For example, pulling a list of friends from Twitter, if you haven’t done it before, and working with the Twitter API would be a risk.

Poorly handled exceptions within the app could jeopardize your impression with the judges and voters, so itemizing these and planning ahead on how to handle them will save you time and ensure you are prepared.

Quality and Completeness

It’s more important to have a good quality app and one that is complete in what it promises than a bunch of almost finished features.

Cut features mercilessly as you near the final stretch, opting for quality over depth. If you promise it on the home page, it should be there and work completely. Otherwise, don’t mention it.

Conclusion

With a detailed plan in hand, and understood across the team (again, this is part of the communication I discussed earlier), your team will be prepared to hit the ground running and won’t need to spend valuable building time with planning and strategizing, which can be particularly challenging when you are tired and emotionally drained.

When competing in a hackathon there are some sacrifices you make compared to when you are creating a product under normal conditions. One major difference is that the product must appeal to the judges and the target audience (if there is public voting). It’s important in a judge-driven situation to understand what the judges will be looking for specifically. Are there categories that you will be evaluated on? What are they looking for in each category?

If the rules of the hackathon don’t explicitly define what you will be judged on, contact the organizers and ask for further explanation. You may also want to ask if they would share that same detailed direction with the judges so you are all on the same page. If the competition is judging you on “completeness” for example, what does completeness mean to them? Does it mean everything that you says works indeed does, or, does it mean the judge can’t think of anything else you could have made the app do? It’s very important in a hackathon to be so explicit with the judging rules that there is no room for personal interpretation. If you as a participant aren’t confident that the rules have made it clear, contact the organizers and work with them to ensure everything is laid out as clearly as possible.

While it’s important to create a great service according to your team’s vision, you may want to focus on elements and deliverables that particularly address the items the judges will be looking for since you’ve chosen to compete in the hackathon. I suggest, that as part of your written plan, you describe what you will do to address each category you’ll be judged against and spend time as a team addressing those challenges.

As important as choosing your teammates is, communicating with them is just as crucial. Some of you may all be in the same location, but for both my hackathons we were spread out. The designer was in Portland both years, and the second year the additional designer was in Michigan. We never had more than two members in the same room.

With Josh, the lead designer both years, I never even spoke to him on the phone until a year after the first Rumble (in preparation for the second). All our communication was done online, without audio or video.

We mostly used Campfire for all our discussions the first time around, including both pre-hackathon planning and during hackathon communication. Campfire allowed us to share images with each other inline very nicely, go back and see notes from past conversations, and collaborate in both real-time and delayed time.

The second time around we used Skype chat (I can’t remember why over campfire) and had some phone calls, but regardless of the technology used, we stayed in constant contact throughout the Rumble, and even prior to it as we formed the plan.

You can also use tools such as dropbox to share files and I highly recommend getting all teammates using github, not just the developers. It will save you a lot of time.

The key to effective communication and collaboration is very simply: committing to the necessity of it. All members must understand how crucial it is; then, stay calm and patient in communication, and stay committed to the goal of effective collaboration.

You might choose to assemble a team before picking an idea, and that’s fine. The order isn’t important, but assembling a solid team is. I’ve had the blessing of working with my best friend since childhood, Steven Pothoven, on both of the Rumbles, as well as an excellent designer and all around great guy, Josh Hemsley.

When I first approached Steve with the idea of competing in the Rumble, I told him that we would begin planning and proceed with the goal to do it, but, that if I was unable to find a great designer to make the site look professional I would drop out and not compete. I simply would not do it without a great designer.

I spent several months trying to find one, even attending the first Front End Design Conference in Tampa Bay. I can’t remember how I ended up coming across Josh Hemsley, but am so thankful I did. We chatted online. I pitched him the idea and challenge and thankfully he accepted. With him on board, and Steve’s excellent Linux and development experience I knew we could attempt to accomplish a lot during those 48 hours.

For the Rails Rumble, the team can be up to four members, so I rounded out the team with Linda Olson, who served as tester, writer, and even produced a video for the app.

Our second time around it was again Steve and Josh on the team, but the fourth member was Sean Farrell because we needed an illustrator to knock out as many badges for Commendable Kids as possible. He produced 80 incredible looking badges.

One of the keys in putting together your team is finding complimentary skills. If you are great at Rails but not so good at setting up a Linux server, then be sure to add someone who can bring that experience and skill. If you are a back end developer without front end experience, find a front end developer to add to the team. Ideally, you’ll each bring a certain expertise to the team that you can focus on during the hackathon.

I’ve heard some pretty awful horror stories of poorly chosen team members, from members that walked out in the middle of the competition and never returned to members who were so poor or new in skill that they were more of a liability than an asset.

The biggest decision is whether winning or participating is your top priority. If you only want to do it for the fun, then you may simply pick the people you would have the most fun with. If you hope to make a strong showing, be sure you surround yourself with sufficient talent. Hopefully, you’ll be as fortunate as I was, to have both. You’ll be spending 48 hours with the team, so be sure you can stand them!

For me, this is one of the hardest parts of the entire application development process. I have a list of ideas I’m passionate about that’s so long, I could never hope to make a dent in it, but naming each one…that’s the challenge for me.

The best advice I can give here is to not let it hold you up. Envision the idea, assemble your team, discuss the vision together over coffee, the golf course or cigars (my personal preference) and then start planning it. Let the concept sink in, and as it matures during planning, something may come to you.

Go to the Rails Rumble archives and read through the past entries and see if anything comes to you and see what you can learn from those names.

I had a few sleepless nights trying to come up with PeepNote and Commendable Kids. The challenge of course, was not only naming them, but getting a domain name that is available. There’s no requirement for a hackathon that you have your own domain name. You could host it at project-name.railsrumble.com, for example, but I think part of the overall first impression and experience for the first time visitor is seeing a professional domain name that matches the name of the site.

One final note. As hard as it is to come up with a name, don’t be afraid to hold out for a great one, and even throw away a good name for an even better one. Before I came up with PeepNote I had firmly settled on, and purchased, Tweepleville.com. I was sold on it at the time, but as the concept developed, I wanted to provide for a future where the service went beyond Twitter. PeepNote came to me during a brainstorming session and I switched at the last minute (about a week before the hackathon started). Thankfully I was open to the change, and I think PeepNote ended up being stronger.

A wise old owl once lived in an oak.

The more he saw the less he spoke.

The less he spoke the more he heard.

Why can’t we all be like that wise old bird?

Though it all starts with an idea, keep in mind it doesn’t end there. While we all want to come up with the next most innovative and original concept, remember that the past winners of Hackathons such as the Rails Rumble, have included an app that helps you keep track of your favorite beers, and another that lets you create links to all your other online sites, even though About.me and hundred other such services already existed.

When it comes to the idea for a hackathon, the most important element is that it be a concept that is easily and quickly understood. While judges will spend the time looking over the site trying to understand it, the average voter won’t. They will click on each site in the competition, look over the home page and then proceed to the next. Most won’t even sign up unless it specifically appeals to them.

I’ve seen apps finish in the top ten that didn’t even work. That’s not good, but, it shows the importance of the simplicity of the idea. As a rule of thumb, the first time visitor should be able to readily identify your concept in under 10 seconds. I believe first impression is one of the main reasons why apps finish strong in a Rumble.

While the app doesn’t have to be the next big solution, it does have to promise value to those who will be judging and voting in the hackathon. It’s very important when selecting an idea for a hackathon to understand the target audience. Again, I believe this is why the apps that have finished in the top three each year, have done so well.

There are exceptions of course, and my entry in the 2010 Rails Rumble is a great example. Going in, I had two ideas to choose between. One was a service specifically targeted at developers (the majority of those judging and voting) and the other was CommendableKids.com. I went with my heart and decided to accept that we’d not appeal to a good percentage. Thankfully, we still finished strong, and even those without kids could appreciate the goal of the site.

In the end, you and your team will have to carefully weigh the passion for an idea with it’s appeal to the target audience in making your decision, and then be sure that you clearly state the goal of the application on the home page and then fulfill the expectations you set.