Midnight Oil

Either I will get flamed for this, or the lack of comments will show how unknown I am, but I’m going to go ahead and make a heretical statement: I did not like Atlanta Startup Weekend (ASW). I felt that it was an interesting experiment, but like most experiments, it was a failure.

In the spirit of total honesty, I’m writing this at home while others are still toiling away on Skribit. I came for Friday night and half of Saturday, but finally had to cut my losses and head home. I was not contributing, not learning, and had my own startup to work on. So, rather than be part of the problem (see Too Many People below), I decided to be part of the solution and cut out. I don’t consider myself a quitter. Time to work on my projects is my most precious resource, and I just couldn’t spend any more of it at ASW doing nothing.

Having been part of many failed experiments, I feel that it’s my duty to look back and try to pinpoint what went wrong and how it could have been done better. A failure is nothing to be ashamed of, but it’s only useful if you honestly criticize yourself and try to correct in the future.

Update 2007-11-11:2300 It looks like I was too hasty in my proclamations of doom. The team seems to have really pulled together and is going to put out a beta release. Still, I think the following criticisms are valid, so read on and enjoy.

Update 2007-11-12:1200 Talking to Jason today, it seems that they were able to wring out a lot of work in very little time. Getting a manager from each different group, having regular releases to the staging server, and assigning individual use cases sounds like it worked quite well. Not to mention everyone pulling together and working hard. So, it seems that I was pretty off-base in my criticism. From what I understand, the following rants only apply until shortly after I left, when everyone started to get organized. I tip my hat to everyone who was able to stick it out to the end.

Too many people

By far the greatest issue is the number of people. Successful startups are comprised of 2-3 people who decide to get together and solve a particular problem or fill a niche, often one they have been talking and arguing about for a while. With ASW, you have 50-70 people who don’t know each other and have no particular focus.

Most of my following criticisms are simply extensions of what happens when you have too many people. Fixing this one issue would go a very long way to improving the experience. On the flip side, ASW wouldn’t be that exciting if only 5 people were invited…

Lack of shared vision

It was exhausting just trying to understand what it was we were going to do. I’ve been on teams of 5-10 where no one knew what the goal was. Growing that to 50 people was simply that much worse. What made it so frustrating was how simple the Skribit idea actually is.

There seemed to be a significant disconnect between what I thought, what the other developers thought, and what the business people thought. In the spirit of “we have to launch in 2 days,” I wanted bare minimum. Add suggestion, vote on other suggestions, end of story. No moderation, no similar suggestion match, none of that. My version was probably too basic to be useful, but it could be done, and possibly enhanced in the future. This was the product I envisioned. Unfortunately, I don’t think anyone else shared this vision.

Now, that’s OK if I was the only outlier. Hey, maybe I’m just stupid, right? However, I think everyone had it different. It never seemed to me that anyone was on the same page about what exactly we were building.

No organized work breakdown

I’ll go ahead and name Erik as the lead developer. He took the initiative to set up the SVN repository, bootstrap the Rails project, and start hacking away. I imagine that he, like the rest of us, was tired of aimless talking, writing, diagramming, and all the other seemingly endless pre-coding activities. So, like any restless developer, he jumped in and started working. A few other developers followed, and we were off to the races.

Between Erik, Calvin, and Nate, (last names elude me…) it seemed that a lot of work was getting done. However, without an organizational structure, three developers is probably the maximum concurrency you’ll be able to get, especially this early in a project when there’s so much foundation to build. Even with only three, it seemed there were quality control issues with people breaking each others’ stuff fairly regularly.

Jason and I noticed this immediately, so we tried to put on the management hat and create individual user stories for the preliminary features of the system. Following along with the UI mockups, we wrote up about three use cases. We tried to be careful to keep the scope small enough that someone could accomplish the use case in a short period. We also tried to make them independent so there would be a minimal amount of stepping on each other.

As I should have expected, none of the developers were all that interested. Why should they listen to us? Sticking our use cases in their faces was just interrupting their actual work of developing. I completely understand this point of view, being a coder myself. Realizing that pressing would be futile, I resigned to simply stay out of the way.

To be clear, I don’t want to be too critical of the core developers. They were doing real work, while the rest of us just stood around. However, the approach made it fairly difficult for any of the rest of us to help. Then again, does a project of this size really require 15 developers? Maybe it just needs three.

No release cycles

Without use cases, requirements, or any sort of work breakdown, asking for release cycles is pretty ridiculous. Still, I strongly believe that it’s worth it to periodically freeze the features and push out a release, even if it’s internal.

For ASW, this could have taken the following form: Set a deadline (time, not features) that everyone shoots for. When that deadline comes, we do a quick feature freeze. Make sure the code in SVN passes the tests and has no glaring errors. Until then, no one starts a new feature. It’s OK for the developers to idle for 5, 10, or even 30 minutes. If it’s taking that long, it means that the code in SVN is poor quality and that’s something that needs to be addressed.

Once the tests are passing, and there are no glaring errors on the interface side, push it to the staging server. Then, crank the developers back up to work on their next use cases. While they’re working, bring in some biz-dev guys to test the prototype. They can make sure we’re all still on the same page! Document any bugs found, figure out if we’re implementing the right stuff, and keep going.

Rinse and repeat every 2-3 hours.

Jason and I did set up a staging server on the Mac Mini that was provided, but learning from my failure with the user stories, I didn’t press the issue about the release cycles. When I left, Jason was periodically updating the staging server. I probably should have pressed harder to get some biz-dev or others to look at what was present on the staging server. I was afraid to press too hard on anyone, since I didn’t feel like part of the productive core group. Who wants to take advice or orders from some guy who’s just standing around?

Technology lock-out

For the developers that showed up with no Rails experience, it must have been a very demoralizing experience. Jason and I tried to help them a little, showing them the Blog in 15 Minutes presentation. Still, assigning them a homework video is a long way from actual mentoring and tutoring. The development, especially the core creation of the models and associations, happened in such a whirlwind that the non-Rails guys didn’t have a chance. There was no way for them to contribute as developers, and that must have felt pretty awful. It sucks to feel useless.

Not all bad news

SW was not a waste of time. Far from that, it was very interesting, and I did learn a few things. Plus, there definitely has to be some kudos handed out to a few people:

Naming Team

The naming team came up with several names, and they were all quite good. I’ve always found this process arduous and usually go with something like www.aprogramtovoteonblogtopics.com or www.rubyonrailsprojectmadeforbloggers.com where I focus too much on the features or the technology.

Luckily for us, we had someone else to handle this important task!

UI / Graphic Design

I didn’t see much, but the UI mockups looked very good. I’ve always been envious of the design people and their ability to pull out pencil and paper and create great stuff. I draw stick figures and they make Picassos.

Good logistics

Lance Weatherby and the other organizers did a great job with all the logistics. The food was good and there were plenty of powerstrips. There was always a room you could go to if you needed a place to discuss something without the constant hum of work. The WiFi was so-so, but I don’t think BarCamp was any better. A hearty thanks to all the people that worked to bring this to Atlanta.

Bottom Line: Fewer people wearing more hats

This is the obvious solution to pretty much all the problems I listed. An ASW-scale project should be doable by a team of 3-5 people. Two coders, one biz-dev, and one or two graphic designers. With a team that size, you can quickly cut through all the communication problems and get to work. Shared vision is easier to sustain, and project progress is much easier to measure.

To integrate this with SW, I suggest that the entire group be broken into 5-person teams. Rather than forming one company, form ten! Choose ten different ideas and push them all the way through to completion.

As long as it’s possible to move from one team to another (perhaps by buying a position in the comany?), there should be enough flexibility for people to organize as necessary. At the end of the weekend, take an hour or two to show off all the projects and discuss what went well and what didn’t. For added fun, hold an IPO where people can buy into the companies they like.

Crazy? Impossible? That’s what most would say about Startup Weekend in general…

Feedback

Am I way out of line? Did we start tagging releases and pushing them to staging? Did all the problems I listed disappear when I left? (Doesn’t look like it) I’d definitely like to hear from others, especially those that stuck it out for the entire weekend. It’s a crazy idea, which usually I like, but I just don’t think it works.

Update: 2007-11-28 Lance Weatherby, the Atlanta organizer of Startup Weekend, has put together a pretty good write-up on the experience. He specifically mentions the need for milestones and leadership, and I would definitely agree. Overall, it seems that most of the people who stuck it out the entire weekend came away with a positive view of it. There’s something to be said for that, I guess.