26 August 2012

Subscribe to Engineering Growth

Stay up to date on new essays and updates on Growth Engineering.

I still remember the first project I ever worked on that went viral.

Cobol on Rails was a re-design of the Penn’s online Course Review system. The original was written as a Senior Design project a decade ago and kept on life support by the University IT.
It was (by the time we got to it) rather outdated. It looked like this.

Original PCR

Cobol on Rails was built in PHP and mySQL. It was the first serious web project that a few friends and I undertook. The Course Review folks were a student-run group who had been trying to find somebody to take over web responsibilities. They were willing to share the data.

We worked weekend after weekend, in 12-hour sprints, learning things like what the hell a border-radius was.
I still recall var_dump as a fond friend; good times.

It worked. I emailed a link the Course Review folks. “We’re done, check it out!” A few of the others emailed their friends.

A few days later, we were on Under the Button, a well-read student newspaper blog.
The initial emails had gone viral as students started to pick their next classes., leading to a couple of thousand unique visitors a day. Every minute between classes that day was spent glued to email, responding to feedback and answering questions. My heart was racing.

The Course Review folks emailed us too. “I can’t believe you guys did this,” they wrote. “You promised not to start a competitor! The Dean is not happy.”

We had to password-protect the thing (the password was ‘password’, and you could tell it you viewed the source).
Students went back to using the crappy old site, and the Course Review folks were mad enough at us to not take any of our advice about UX improvements seriously.
The experience stuck with me - the substantial improvement we made, and the politics that brought back the status quo.

I was friends with Cynthia from Penn’s Student Government.

She was spending the summer working on student textbooks. The problem was this: Penn’s bookstore made absurd margins buying back used books.

The old, student-run book exchange (BetterThanTheBookstore.com) had closed. In the summer of 2010, following Princeton’s lead, Penn’s Student Government decided to start their own Book Exchange, Penn Book Bazaar.

** Cynthia **: “You know Django, can you make this thing work for us?”

I had no desire whatsoever to be a peon for the Student Government.
They went ahead and did it on their own. The result was simple but not ugly and pretty successful.

Penn Book Bazaar

Marketing isn’t so hard if you can email the entire school whenever you’d like.

Meanwhile, we hosted our first undergraduate hackathon, PennApps.

The winning team built an app called SEASPrint, which let students print anywhere in the engineering school directly from their phone.

SEASPrint was awesome, and was more than a prototype - it worked. I used it all throughout college. With time, it would probably start to fall over unless somebody made sure it was up-to-date, and would be forgotten unless discoverable. But the team had no particular interest in supporting it long term. That sucked.

Eventually, it clicked

Campus tech does not have to suck. Apps do not have to become outdated or unsupported. Developers don’t have to quarrel with the administration.

Working on campus tech can be rewarding, and deserving of talented engineers’ time. Building something your friends use feels great.

And so, we started PennApps Labs, a student-run development shop that creates, adopts and maintains student-run campus tech.

Labs Logo

** PennApps Labs in a nutshell **

  • PennApps Labs pays ~5 students a semester TA-like wages to create new applications or update existing ones.
  • Funding comes from the school’s administration and Student Government, which makes cooperation with existing organizations substantially less painful.
  • Other successful student-created projects are supported and promoted, with a potential goal of adoption. Labs helps good projects from becoming stale and lost in the sands of time.
  • PennApps Labs projects strive to be open. That means open-sourcing whenever possible, accepting and soliciting community contributions, and establishing open APIs for any data created as a side-effect.

Labs README

I believe Labs is a model worth forking. The problems Penn’s campus tech faces are not substantially different from the problems at scores of other schools. The sorts of problems that Labs aims to fix benefit from outside collaboration and contributions.

I am working on a README that should serve as a guide for starting a sister organization at another school. Drop me a line if you’d be interested in trying something similar are your school, and I’ll make it a priority.

Tags: #labs #advice