I want my...I want my J..V..M...

That ain't workin...

I love the iPhone, and what an amazing platform for development! As soon as the SDK became available I downloaded it and started to peruse the online documentation. As usual the apple quality of documentation is superb, and the tool support is equally fabulous (if you use a mac :), the lack of interface builder support in the beta SDK notwithstanding. I even like the use of Objective-C, a language that Apple (and NeXT before it) has steadfastly remained loyal to for eons. In fact, as a former C programmer it was like slipping off my Java-esque plate mail and slipping on a favorite jacket, worn in places, but extremely comfortable to wear. But then, you discover why you stopped wearing it in the first place... its got a hole in both pockets, so all your loose change clatters to the floor or something equally heinous.

No, this isn't about to degenerate into an anti-C rant - I'm too much of a loyalist for that - but what did surprise me was that they didn't include garbage collection for their iPhone runtime environment. It's a feature they've recently begun to support in their Cocoa development for OS X, from 10.5 (Leopard) onwards, and gets rid of the need for the somewhat complex reference counting scheme that they've used to keep track of heap usage in previous versions. In an environment where they really do need to make efficient use of memory, you'd think that garbage collection would be a trade-off worth making - especially as many newer developers who haven't had to manage their own heap space will be flocking to this platform because it's damn cool! Yes, the tooling apple provide to detect memory leaks is excellent but thats not the point - why not eliminate the problem at source and institute a lightweight garbage collection scheme? It has certainly made me re-evaluate my initial "gotta build something for this device" rush of excitement, maybe I'm getting old but I just don't wanna bother hunting down memory leaks any more - I'd rather focus on solving real issues like the problems that surround the thing I'm going to build!

That's The Way You Do it...

Well, it seems that Sun has decided to build a JVM for the iPhone, using the various Java Micro Edition JSR's. That's good stuff as far as I'm concerned. While that Java platemail may be a little uncomfortable at times its nice to be wearing it when fate comes at you with an axe :) From a legal perspective I'm not sure HOW a JVM is gonna get past the fairly explicit wording of the Apple SDK licensing, but IANAL, I have high hopes. Clearly this will meet my curmudgeonly garbage collection needs, but they'll need to be clever to massage those vendor-independent API's in JME to support some of the as-yet unique features of the iPhone. What I don't want is basically another little box for writing bland-looking Swing apps on, IMHO it must follow the style, look and feel of the existing iPhone interface, anything else would be sacrilege!


Money For Nothin' and Yuh Chicks For Free

Whatever your choice of developmental poison, the iPhone is clearly big and getting bigger by the day. The fact that Apple are using iTunes as an exclusive distribution channel is *great* news for independents - your software will be on millions of desktops with little effort. The fact that you pay them a third of your profits (I believe) is well worth it! I just hope that something can be worked out so those cool iPhone based jars that i and others want to write will get the same status as native apps. I guess time will tell.

(with apologies to Dire Straits)

The Invincible Machine...Mark II

So, its been a while! LibraryScan was my first product and it taught me a lot of what to do and a whole lot of what NOT to do. The product itself wasn't a bad one actually, but it just suffered from undernourishment. Undernourishment in a support and update sense, but most importantly a distinct lack of marketing - simply "spreading it around" every shareware site in existence was not enough. I'll learn from that in future. In my personal life the whole life/work balance wasn't right to really strike out on my own in an entrepreneurial sense - but kids are older, I have a job back in academia that I really enjoy and it gives me freedom to do this - so the "I've got to get out of this horrible situation at work" pressure is well and truly off!

So Mark II! What am I working on? Well a couple of different projects at the moment. My attention span is such that working on multiple things at once will get the best out of me in a work sense. If the current project gets old, well I'll move to the next one. I just hope that the number of projects is a) manageably finite and b) I go back to them and get one or more completed! We'll see - but anyways it'll be fun.

Here's whats in the oven at the moment:

1) A framework for building strategic wargames (yes the old hex map and counter stuff! I love it!). This will be the basis for an number of historical wargame titles I have wanted to write for 20 years.

2) A web application for writing, reviewing, sharing, collaborating and publishing works of fiction.

...I'm sure I'll add to this as I go along.

Pulling the Rip Cord

Ever since I've been in the US (I'm a transplantee from the UK), I've bounced from contract position to contract position. Some have been challenging, some have been incredibly stressful, some have even started off being interesting. The problem was that after a not inconsiderable amount of time I started getting bored. Very bored. Bored to the point of looking at the clock every 10 minutes to check to see if it was anywhere near time to leave. To stave off the boredom I'd typically change contracts, by waiting until one reached a decent conclusion point and then move on. It was pretty easy to justify in my mind... "employer X sucked", "employer Y has put me on deadend project Z" and so on. But after a while the pattern was becoming increasingly obvious even to me. There wasnt really that much of a problem with any place I worked at (ok, with a few exceptions), the problem was me - I just wasn't motivated enough to get my butt into gear to solve someone elses problem. There was no personal "buy in", the projects were designed to meet some obscure functional/profit goal of the employer in question so I found myself sitting in endless meetings with the sentence "...and I should care ...why?" continually firing through my synaptic pathways. In my mind, such apathetic thoughts quickly lead to poor, or barely adequate levels of professionalism - so it was time to consider a better alternative - actually going ahead and working for myself, inspiring myself... oh and whining a lot less about life!

As I have stated, I want to write software. Software that is of interest to me, myself and I... Software that I'd like to sell to like minded individuals, that would be cool enough to inspire a passion to build and maintain, and hopefully inspire similar emotions in my customer base. So, to meet this objective I finally started to write my product last December. Its entering a beta phase now. Its called "LibraryScan", it runs under windows, and is designed to provide a catalog of all the geek acquistions I have, movies, games, books (especially books!) I have accumulated. It joins a number of other luminaries out there in the market, in that it can scan barcodes on the back of items using a "run of the mill" USB WebCam, and place it in a repository - along with nifty full color pictures. I wanted to build an app with a degree of cool appeal to me (and I hope others!), but something that *I* would use in my day to day life, not something to sell or manage stuff for other people (incidentally I need beta testers - please drop me a line at pete@objectlearning.com if you'd like to join a short public beta, and get a free copy at the end... and the undying gratitude of millions! :-).

Anyway, armed with this near-finished product I decided to pull the ripcord and establish myself as an independent. Before I go on, I should mention that I have the advantage of having a wonderful wife who actually has a decent career in her own right - so there was and is, at least some degree of financial and personal security in the background. However I felt that I should establish a revenue stream to keep some money coming in, while I make the final push to get my product ready for consumption. So I called up some previous contacts and decided to do some contract training and course development. In a previous life I had done (and enjoyed) some contract training, as well as having a long spell in academia in the UK - so it was something I could leverage to keep the income spigot at least dripping... So thats what my primary income source is going to be for the near future - build courseware, and doing training (www.objectlearning.com). This has the advantage of keeping me at home, and gives me some time to work on my product - and to develop new product ideas. Basically to do the grunt work necessary to turn my company into a fully fledged micro-isv. I just have to be careful that the side work doesnt completely consume the free time I have marked out for myself!

So I went to my employer and told them of my plans. They were good about it, sorry to see me go and all that good stuff, but there was an interesting subtext of "you are completely insane for trying this!". One boss (who I actually like and respect a lot) went to the trouble of asking me to state my software ideas and then one at a time saying things like "that won't work", "that'll never sell" and so on. A little discouraging, but wonderful fuel for that terrible cliche where the successful entrepreneur triumphantly proclaims "...and they told me it could never be done!". Well, my objectives are a little more modest. Rich is good, but achieving an adequate income is really all I want, and really have the right to hope for at this point.

In preparation for making the final step, after securing my income has been to do a decent level of research, see what others have to say and what they have personally experienced. I have to admit I hate self-help books, and usually scoff when I see people on aircraft reading "How to get that corner office", or books of that ilk - if you need the book, if it doesnt come naturally, then you dont have a chance! Well thats arrogance, pure and simple on my part. I read Guy Kawasaki's "Art of the Start", and yes, it's is full of those annoying peppy phrases and buzzwords that you probably should repeat to yourself every morning when you leap out of bed. But its good. Its hilarious. Its inspiring, and definitely worth a look. I have also found that http://www.microisv.com (linked on this page) is an awesome resource - and really was instrumental in convincing me to "have a go".

So I've quit my job, have a pretty reasonable income from building training resources (and thats pretty interesting in its own right - I get to learn lots of good stuff!) and am currently just about to push my first offering out to public beta. So its a reasonable time to pull the ripcord. I don't need a golden parachute to unfurl, just one enough to keep me afloat will do.

It's Just Me Dude

Part of my day job as an architect is to suggest/cajole/enforce "best practices" within the organization I work in. This runs the gamut from a repeatable and measurable software development process, to establishing solid principles for large scale architectural design, right down to "design in the small" at the implementation level. In a large corporate environment, at least a nod towards some or all of these issues will serve you well in the long term. Big money, large distributed project teams, aggressive deadlines, and a substantial legacy application base mean that techniques, practices and technologies that seemed to be firmly rooted in academic circles, or just "wouldnt it be nice if we did it this way" flights of fancy are seen as emergent ideas, or are now gaining traction in the main stream. You know the sort of things : iterative development/delivery cycles, eXtreme Programming (XP) and agile development are shunting aside traditional no-design/waterfall approaches, slowly but surely... Design and development technologies, patterns, frameworks, components provide "out of the box" guidance on how to do something, or just do it for you with minimal effort on your part. Requirements, or at least aspirations at the enterprise level have grown exponentially since the days that computers had names like "MultiVac" and "GorgoTron", and required the resources of a decent sized principality to build and maintain :) Many of these techniques, practices and tools simply enable us to deal with the heinous complexity of our requirements and environments, they dont make software development easier per se, but enable you to manage, partition and organize the complexity of your current uber project ... oh and make sure that the next slob who is paid to add to it can actually understand what it does!

Jump to the other end of the spectrum. The adventure and romance of a single, lone developer building and supporting a small set of applications in a micro-isv. In building my first product I wanted to apply at least some the best principles and practices of my day job, but only where they made sense. After all we are dealing with a huge difference in scale here. The temptation was of course, to just go for it, take my idea(s) and rapidly realize it as an evolutionary prototype that would grow into a fully-functional product... of course such an app had every chance of looking like a mutant spaghetti-like shambling mound of horror... But then, I remembered that the timescale and effort would be both extended and inconsistent in terms of effort. When I add in a hack, I usually quickly forget why I did it in the first place, comments in code help of course, but there is usually a "relearning curve" as I piece together the circumstances that lead me to perform such a heinous act in the first place. So I decided that I would at least try to engineer my code in such a way that it conformed to best development practices .. at least as I understand them ;-) Hopefully it would make it simpler to understand, and re-understand when real life kept me away from product development for an extended period of time. There are other benefits: extendibility - my customers will expect new features as my product grows - I wanted to think how to build upon my product in a consistent fashion. Maintainability : hey I know we all write bug free code, but sometimes I fall asleep at the keyboard and bad stuff happens :) In fact anything ending in "-ility" is probably a good outcome of such a move! The trade-off? Well its gonna push out my delivery date, but in the long term I think it'll be worth it.

But to get back to the main gist of this post. What best practices could I beg, borrow or steal to help me out? The main thing for me : it has to be lightweight .. and to be honest I think this applies to any scale of development effort. Onerous heavyweight tasks beyond the actual production of code (e.g. heinous "non-productive" deliverables) bog down the development effort with very little return... if they are not completely ignored that is! For an enterprise scale effort a heavyweight approach to such documentation/deliverables (which *are* important for accountability, scope, checkpointing, budgeting etc!) can be a crippling burden, at the individual level its just plain dumb.

Ok, lets start with process. Iterative releases of the product seemed to be an attractive proposition. This also falls in line with good advice I have read elsewhere: "get it out there warts and all, as quickly as possible". Each iteration of the product will add new features, as part of my long term plan of world domination through rich application functionality, and of course, responding to feature requests from the adoring millions who will buy my offerings. In order to actually get to my 1.0 release, there will, and have been, a number of internal "iterations", enough to establish a baseline and infrastructure that the first public release will have to have in place. With each iteration comes a degree of lightweight planning. I have been doing this as a simple list of detailed features I want to include in each iteration cycle, nothing more fancy than that.

Within a given iteration, I'll make sure that I understand "what" I want to build before I go ahead and commit to anything else. Again, short notes describing a feature, diagrams for screens and general doodling that helps me get a grasp on the problem, and tease out all those little "gotchas" that inevitably lurk within is a good exercise. Practically speaking I do all my note taking on a Tablet PC with stylus ... I'm expert at losing pieces of paper so at least I know where my notes are. I just have to hope that I don't lose my tablet.... That really covers the requirements piece. It's a world away from use cases, requirements documents and screen prototypes, but in this case its more than enough to get my ideas from my head and onto paper for future reference.

Design... thats quick too, but I do put some thought into how I'm going to do something before I start writing it. A few scrawled UML diagrams are worthy enough to do the job here - maybe a simple class diagram showing the major dependencies, and a sequence diagram to show the flow of control if its gonna be complicated. But thats it - again MS Journal on my tablet is the favored basis of representation.

The development itself... thats where the low-level design work gets done, oh as well as building the stuff that actually executes :-) I'll try and consistently add to my burgeoning code base on a feature-by-feature basis, but sometimes the need to go ahead and write another piece of infrastructure sometimes gets in the way. Also, I have to admit, if the feature muse bites me in the butt I'll often go do something else in the application just for the heady spice of variety.

Testing... not the most exciting aspect of software development, but to release a quality "bit of kit" it's essential. My unit testing (bless the JUnit gods) is fairly thorough, and on a larger scale I have a set of test plans that are designed to send my application into horrid spasms of death if I havent done something right :) However, never fear gentle reader, my application will have a cast of millions involved in its testing, a closed, or maybe even open (!) beta process made up of individuals who wont be shy in coming forward if something is quirkly, nasty, broken or just plain evil.

So to end this ramble, "lightweight semi-formality" is the order of the day. There *is* a process, there *are* requirements, a clear purpose in design, and thought that goes into the production of code - shaped (I hope) a little by what I have learned in the "real world". I even test what I've written :)! That may be too much for some... or too little by far for others, but hey, at the end of the day its just me dude.

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! :)