Copacetic

Ace King, check it out!

Joe's ten rules of commercial software development

with 14 comments

These are rules I’ve gathered in my head over the past ten years. I can’t claim ownership of them all and I’m sure they have been articulated in many other places. A conversation at lunchtime about how hard it is to do commercial software development prompted me to do a brain dump.

By commercial software development I mean making a piece of software in order to sell it to many customers (as opposed to a handful) or to provide a service used by many customers.

  1. 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.
  2. Build it – Then Sell it: The corollary sell it, then build it, is a different business, called consultancy. A Consultancy business doesn’t scale the way a software business does because you build a different product for each customer and sales is related to the number of associates you can recruit to do the heavy lifting. Building it means finding a niche and timing it just right so that the market is ready for your product. Irish software companies can build the stuff but their timing is usually off (they often suffer from being too early).
  3. 6 months – 12 months: It takes 6 months to build anything worthwhile and it takes another 6 months to raise the quality to the level where you can let it out of the house without a curfew. But what if I hire really great people, I hear you say? Well if you hire really great people, then their and your ambitions will be greater too, so you end up building something more complicated which takes 6 months…
  4. Show and Tell: Get the development team to demonstrate progress every week, by running a demo of the current code base. If they miss a week, then make doubly sure you get a full demo the following. Do it from a full install of the kit, not a development environment.
  5. Build the Installer first: Installers keep you honest, stop you fudging development problems with patches, isolate you from the development environment and force integration early.
  6. Project Plans are good: Microsoft project gets a lot of stick (and I’ve given it some myself in the past) but I can’t think of a better tool for giving you a ball park view of how long a piece of work is going to take. See a future post for how I plan. Remember the map is not the terrain, the best value of a plan is to be able to assess when half the time is gone, whether half the work is done.
  7. Using is Testing: Unit test suits are good, automated test suites are good, user acceptance test suites are good, but there is no substitute for sitting down and using the product. Better still, get somebody else outside the team to sit down a use the product. One hour watching a novice user with a new piece of software is worth 24 hours of automated test.
  8. Don’t extend the date – cut the features: You have to ship it, otherwise you end up like Vista or worse DECnet Phase V, constantly revising your feature set to meet changing customer requirements. XP has lots to say about this and its prioritisation mechanisms allow you to make cuts easily.
  9. Fire the asshole:You have a team, its working pretty well, you have this one super guy, but hes a bit of an asshole, rubs people the wrong way, gets abusive when asked for help, schedules, dates etc. Get rid of him. Software development is a team activity.
  10. Its a marketing function: Commercial software development is about supplying a customer’s unmet needs and/or desires. Its not about J2EE, Spring, Web-Services, Python, C#, Design patterns etc. etc. That is software engineering which is a sub-discipline of commercial development.
Advertisements

Written by Joe

July 19, 2006 at 2:57 pm

Posted in Uncategorized

14 Responses

Subscribe to comments with RSS.

  1. #10! What’s this heresy?

    Darren

    July 19, 2006 at 5:17 pm

  2. Hey Darren, I’ve come full circle.

    Welcome to Web 2.0! Web 1.0 was about engineering, Web 2.0 is about marketing.

    Maybe I should add that to the list.

    Joe

    July 19, 2006 at 6:28 pm

  3. Who’s this Jerry joker?

    Darren

    July 20, 2006 at 5:28 pm

  4. Should be gone now, do a refresh, just some comment spam.

    Joe

    July 20, 2006 at 5:32 pm

  5. […] 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. […]

  6. […] Via Darren Barefoot, here are ten rules of commercial software development. I particular like #7: “One hour watching a novice user with a new piece of software is worth 24 hours of automated test.” […]

  7. #9! Ha, every team has an asshole… I think its part of the deal! (anybody in mind?) … heheehee

    Bref Murdoch

    July 21, 2006 at 12:21 am

  8. There are two of us in the team. Only one of us refuses to do things. Guess I’m the asshole 😉

    Johnny K

    August 2, 2006 at 12:02 pm

  9. […] I seem to have hit some weird threshold in stumbleupon for the article Joe’s Ten Rules of Commercial Software Development. My webstats are up 753% for the article with 137 visitors today. For comparison I usually get about 40 or so visitors per day. Anybody know how stumbleupon works to promote your site? […]

  10. […] Dontcha just love external validation. Robert Sutton also believes in firing the Asshole (see rule 9). […]

  11. You said it, Joe. If someone can’t work in a team … remove them! This is something corporate team building programs DON’T teach. They encourage a team to “build” and work together. But, even though labor laws and regulations make it difficult to dismiss staff, it will be the best thing you can do with a disruptive team member. Actually, for this reason, I have started to work with developers in India. So far it has worked out fine. But if their teams, or individuals, don’t work well for me I can easily slip away to someone else.

    Len McGrane

    December 8, 2006 at 2:23 am

  12. Context, Context, CONTEXT. All of these things are true… sometimes. Maybe even most of the time, but if you don’t remember to take things in context you’re sol anyway

    Toby

    December 8, 2006 at 7:37 am

  13. #8 is wisdom applied to development! Target dates keep on slipping when certain features refuse to cooperate, or simply don’t do what they are supposed to. In other words, rule #8 boils down to applying rule #9 to those asshole features 🙂

    Ozgen

    December 19, 2006 at 10:06 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: