Joe's ten rules of commercial software development

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.