The Social Networking Beast

Heather
11/17/2007 - 9:19am
Printer-friendly version

I've been developing software for years. Yes, I remember Authorware! My latest software project is a social networking site at www.digitalwish.com. Wow! what an eye opener. Developing social networking "software" for Web 2.0, bears no resemblance to the production processes we used when developing CD-ROM games, or even web subscription services. Anyone considering it, should be aware of a few things first! 

You can't plan in the same way.  Back when I was developing computer games, I'd write a 500 page spec to describe every feature in the program.  The team could be managed easily because there was a clear and distinct roadmap.  Staff trust factor=low. "Follow the spec or it's not going to work!" Development time was very noisy with everyone cross checking that audio matches graphics, matches characters, matches storyline..."  Only 10% of a budget would be allocated to testing.

With social networking, we have a 1-3 page spec, that resembles a "To Do List." No one is given a roadmap. Staff trust factor=high. "Make me an address book feature and let me know when it's done!"  Development time is very quiet.  A programmer will work silently for weeks until the fateful day of "Hey, check this out..." That's when testing begins.  And I don't mean testing, I mean testing and re-testing and re-testing again. As much as 70-80% of our effort (and budgets) will be spent on re-working features that are already built.  This is where we figure out how to make those features that churn users.

Web 2.0 development is the definition of change in the purest sense. Beware of approaching Web 2.0 development with a software mindset.  Your budgets will be skewed in the wrong direction, and you'll never have enough development time left to "make magic!"

Cathy Davidson

So R and D is Expos Facto

Hi, Heather, That is a really fascinating comment. It makes sense, that in essence a lot of the r and d happens AFTER the release, after testing and re .. . testing by multiple users. I wonder how much business schools have accounted for this? I know with HASTAC we decided really early (2002-03) not to have a game plan and to have a mission that would stay somewhat constant in the most general terms but that itself would be shifted and emended by users and not be constant. It's fascinating to think about that, technologies and virtual institutions, and expos facto r and d.