Joe’s Ten Rules of Software Development

Joe is a client, friend and former boss. He’s very quotable. I shall always remember hearing him across the cubicles, mocking a member of his team by paraphrasing Bon Jovi lyrics: “Shot to the heart, Michelle, and you’re too late. You give software development a bad name.” You kind of had to be there.

Regardless, he’s assembled a list of rules for building software to sell to the masses:

100-1: This a good ratio of end-users to developers to aim for as a starting point. With less than this you don’t get feedback and the feedback you do get will tend to take you in strange directions. Remember if you build a stadium you have to fill it every weekend to make a return, software works off similar ratios.

Rule #9 applies to any industry, and I felt strangely endorsed by rule #10.

Because I’m trying to spend a little more time on sites like Digg, I have dugg (have digged? have dugged? did dig?) this.

Written by dbarefoot

Darren Barefoot is an author, speaker and digital strategist. He’s the co-founder of Capulet Communications, and co-author of “Friends With Benefits: A Social Media Marketing Handbook”.

2 comments

  1. 100 to 1? The software product I work on has over 100,000 users. That means we need a development staff of 1,000?

    Uh, no. Besides, feedback should be going to training, support, tech. docs, and product management, not to the actual developers.

  2. I have to agree with double-plus-ungood. While develop software for a captive audience (in a higher-ed setting), I can’t imagine that this ratio scales well. Or maybe it works well for your expected initial user population, not the long-term user population. Or maybe I’m just bitter because I only have a five member team of developers (about 1000:1) to automate the personel transaction business process for our campus and they want it done in four months 😛

Comments are closed.

%d bloggers like this: