Saturday, February 26, 2005

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.

Mission : Possible

This blog will be dedicated to documenting the serious business of starting a "micro-isv", a one(?) person independent software vending company, from product inception and development, through to marketing and stupendous riches, and all the trappings of fame that I'm sure will follow ;-)

Lets start with me, the one man in the micro-isv equation. I currently work full-time for a company at the heart of the railroad industry in Cary, NC as a Software Architect. Java is my chosen implementation poison, having jumped on the bandwagon early in '96, and religious flamewars aside, I havent seen any reason to go back to C and C++ beyond performance, and a hidden fetish for controlling my own memory deallocation :) I have a wife and two small kids, making free time a bit of a luxury... but I'd like to try and dispel the notion that such a common domestic scenario isn't a mission:impossible plot when it comes setting up and running your own company. Well, I guess we'll see!

The company is called "Bambleweeny Labs", a homage to a late and great writer who also came up with one of my favorite all-time terms: "a horribly be-weaponed chamelioid death flotilla"... confused? sorry. The purpose of said enterprise is to achieve the following:

(1) Build software for an audience with tastes and interests not dissimilar from my own (and believe me thats probably not as esoteric as you think). Such a goal is self-motivating in the sense that I'll be building software that ultimately I, and you may like to own. I'll have fun constructing it, raving about its meaty goodness to anyone who will listen, will joyfully go about adding new features and you'll be happier for it. The alternative for me, would be to continue writing good software, but without that personal stake, for requirements that are much bigger than the simple you and me equation - i.e. the daily grind :), which brings me to my next point.

(2) Do this full-time! I want to build my own products, interact with my own customers, basically do it all myself. At the enterprise level, where I have worked for a large amount of years there are so many forces at work, political, technical, nonsensical...Here, any irrationalities are my own :-) A note : there is no bitterness here, just a desire to go it alone... I've enjoyed doing this kind of work but its time for a change of direction. I have a number of advantages on the pragmatic side as well, my wife has a full-time job, she is supportive of my desire to go forward with this ... but only if I can demonstrate a solid return ... oh and be a bit more organized than I usually am with all the personal paperwork that goes on with running a company :) So, basically if I am successful I can happily pull the rip cord and go ahead as a standalone micro-isv.

Ok, thats enough for now - a vague but uplifting mission statement, next I'll talk about where I am in the product development lifecycle for my first release. A taster... not too far off! :)