Don’t get caught in a web of time sinks
Tips on how to succeed in the 6.470 IAP web programming competition
The well-rounded students use IAP for vacation, avoiding the winter weather in California, or embracing the winter weather in Maine. The inquisitive use IAP to take classes in interesting subjects, such as Medieval cooking, or Japanese flower arranging. And the masochistic decide to spend IAP slaving away on 6.470, MIT’s web programming competition.
I was in the latter camp, and I spent almost 100 hours (yes, I kept track) working on Streetfarer, a website that helps you explore your city by generating a random walking path that passes by locations that might interest you.
Although I did sacrifice my last IAP to 6.470, I only regret not competing sooner. Deploying an app teaches you aspects of real-world software development that problem sets do not, such as how to handle frustration in development environment configuration. As a graduating senior, I will not have the opportunity to compete again, but I wanted to pass on some advice for next year’s contestants.
Developer time is your most important resource. You only have three weeks to make as good a product as you can.
Even before the competition starts, you can start preparing your development environment. It is worth spending time in the beginning improving your efficiency so that you can write code without roadblocks later. I only really started looking into the technologies we needed to make the website when the competition started, which might have been too late. It took me a week to install the postgres database, hook it up to Django, and deploy it to Heroku (although I lost two days because I messed up the kernels in my Debian laptop and had to re-install my OS). That week of time could have been used to work on the site.
Another way to save time is to make sure everyone on the team is developing in the same environment. The designer on our team had difficulty installing postgres on her Mac, and consequently, she developed the front end in a separate file than the real web app. Manually integrating her front end design into the Django templates was tedious, error-prone, and inefficient.
Using frameworks and external APIs are good ways to get a site running quickly. Instead of writing our own algorithms, we used Google’s APIs to both select locations and generate paths. Although the paths they generated had some problems, such as being of unpredictable length, it was not feasible to create our own path algorithm when we had so many other aspects to work on.
UI is the most important aspect of your website. Forget your fancy algorithms and secure login systems. The only aspect of your website that users and even judges will see is the front end. If you have the “wow” factor, such as the team which created a 3D model of energy use in the city, then that’s most of the points right there. It might be worth recruiting a member of your team who specializes in design.
In my experience, the front end was more difficult than the back end. Once you pick a backend framework, the steps you need to take to use it are straightforward. Install the database, create some models of the data, hook up some URLs — all the instructions were available online. The front end was more confusing because there were a lot more feasible options. You could create your own interface with HTML/CSS/Javascript, or you could use any number of frameworks such as Angular.js or Backbone.js. We ended up using a mix of Angular, Backbone, and custom CSS to style our website, which was probably not the optimal choice.
Communication. Everyone should know what technologies the site is using, and what each person is working on. We held meetings about every other day, which helped orient us about what to work on.
Code should also be communicative. Beyond comments, the version control system Git allows code to be shared among each person in the group. Committing early, often, and to completion allows each member to see what the others have been working on. Plus, it’s good practice for collaborative development.
Unfortunately, there was an incident at the end of the competition in which poor communication led to wasted work. Two members of our team were working on a different version of the website interface than the designer. Since these were parallel versions of the site, only one interface could be used, so one version of the site would inevitably be wasted.
Decisions must be made firmly, unilaterally, and quickly. There isn’t enough time to make a whole bunch of mockups or to test a bunch of concepts. In the very beginning, we brainstormed website ideas for each of the themes of the competition, but we decided on our final idea very quickly, and we were committed to implementing that idea.
Not all of our decisions were that straightforward. I thought it was a good idea to come to some sort of standard regarding how CSS classes should be named. There were two viable options: using _underscores_ to separate words or using -dashes-. The designer was accustomed to using underscores and I had a slight preference for dashes, but I couldn’t think of a justification for dashes. At that time, we decided on underscores. Later on, I realized that the CSS classes in Bootstrap all used dashes, and suggested we change our standard to dashes.
Big mistake. Trying to change all incidences of underscores to dashes introduced a lot of user interface bugs, and our designer spent a day trying to fix it. We eventually abandoned the standardization attempt. If we were planning on making a long-term, maintainable website, it would have been important to make our name schemes consistent, but for this site, it wasn’t important.
Be ambitious. Our team of a 6-3 freshman, a 6-7 senior, and a course 4 master’s student could have applied for the rookie division, and that was our initial intention. But there were more prizes available for the main division, and we were told that there were fewer teams competing in the main division, so we decided to switch. And what do you know? We won 1st tier honorable mention, for 1,000 dollars. If we had competed in the Rookie division, we would have needed to win 2nd place to get the same amount of money.