The Write Way?

As I've actually started product #1, and have been steadily working away at it since December 2004, let me give you an idea about how I've decided to approach this whole micro-isv thing. Although you may gasp in amazement this isnt the first time I've decided to go it alone :), so to actually try and be successful I've decided to try and establish a couple of basic principles. Nothing profound here for sure, and much of it is the distilled version of good advice I've heard elsewhere, which has made sense, so I've decided to er, reuse it here.

1. Write What You Know (or can easily find out).

Isn't this the advice they always give to people who want to write a successful book? I guess the same can be said for software too. One of the joys of the development profession is that you get to experience a wide range of industries if you follow a typical career path. I've worked in defense, banking, .coms, insurance, healthcare, energy, transportation - to name but a few application areas. Do I "know" these areas? No! (ok, well maybe a little) In the main, much of the requirements came from people skilled in the business side of things who had devoted their time and effort to become (or be volunteered as) domain experts. In micro-isv land, unless you have such an expert on tap, the requirements come from one person. You, or rather me. So the key objective has been to find an application that would build upon "domain knowledge" that I already possess (or can easily research). Technical skills just arent going to cut it unless they are backed up with a decent knowledge of the application area my product will address...would you as a potential customer and user want it any other way? A true story : In the UK, where I grew up, a friend of mine sincerely believed that airbags in cars were activated by your head hitting the dashboard during an accident. He subsequently went onto a career in the car insurance business ... you have been warned :)

2. Write What You Can Manage

Since 1998 I've wanted to write this uber-mega-application for managing reusable software components. It would be a vast repository with lots of whizzy features that would let corporations catalog and store information about reusable software they used and/or produced. It would have automated processes for searching, cataloging, publishing, submitting and generally doing tons of wonderful things to those components. It even meets my first "Write What You Know" criteria, I actually have a PhD in software reuse, so I can lay claim to at least having a reasonable understanding of the application area. I've even started it a coupla-three times, produced requirements, detailed designs and even some code. The problem? It's just too damn big. I'd never have enough time to finish it. I'd estimate that it would take me a year, maybe two full-time to get it in a form ready to sell. Time I just don't have right now, and probably never would. So I've decided to keep it manageable and build something that one person can reasonably construct and maintain. I therefore have an excellent chance in scraping up enough time to finish it, and do a good job to boot. This seems to be working, I started Product #1 on December 10th 2004, and have a fairly decent chance of getting it in shape for a March/April 2005 release. Thats a far more manageable workload :)

3. Write What Interests You

I can't emphasize this enough - for any project. I feel that my chances of success have been drastically enhanced by picking a product that I *want* to build, in an application domain where I would *want* a solution that my product will ultimately deliver. The alternative (for me) is just too tedious to consider as a career for the rest of my life. If it didnt "float my boat" I believe my motivation and energy with respect to finding time to actually complete a given product would be severely diminished.

4. Write What You Can Sell

At the end of the day, assuming I have 1-3 above licked, then the trick is making sure that the product is going to be something other people are going to want to buy. I've done some reasonably thorough, although certainly amateurish, research into the market(s) I want to address ... and I've convinced myself that I have a saleable product or two in the pipeline, but the "proof of the pudding" will be convincing others! One of the challenges of making this a going concern will be getting the word out to my potential customers, and coming from a technical background I have no illusions that this is going to represent the biggest personal learning curve, and the greatest factor in my clearly inevitable plan to dominate the universe. Watch this space.