I’m a “solo” developer – a “micro” ISV in the truest sense. Everything comes down to Me, Myself and I. While I have a “silent” partner, and no disrespect implied or intended to my “silent partner”, at the end of the day nearly every decision I make, whether it be code, features, UI, marketing, site design, business structure, utilities, equipment and everything else pretty much comes down to me.
I’m not complaining here, this was the arrangement when I started and I’m delighted to be working in this arrangement, both of us are.
Bob Walsh has 47Hats.com as his blog domain name. It’s a “nail on the head” domain name. It implies the reality of a micro ISV and the fact that, probably more than most micro businesses, the principal performs a plethora of roles that the average punter never pauses for a moment to consider.
And why would they?
This year, 2008, I made a decision. It’s been well documented throughout this blog. I won’t go painfully over the details of that decision in this post other than to say I decided to take the idea for a new product and build a multi-media software company. While the idea for the product is not unique, has some competitors and is something I have great affection for I was, and am, adamant that this time around it was a company I was building, not just a product.
In June this year I admit that in some respects I got a little bit lost in terms of bringing the product to market. I can’t resist a challenge. So June saw me trying to bring a product to market in 30 days. Very few of the participants of this “challenge” realized their goals. Though some did.
For me the 30 days galvanized me into producing a product that I labeled prototype. The inner analyst in me refused to allow me to release it. I think some people were disappointed in this decision (developers following the 30 days RSS feed).
But I wasn’t. For me it was an affirmation that indeed my mindset had changed this time for the better. There is more to “quality” than “shine”.
For me the 30 days represented 405 man hours of solid product development. I don’t take breaks when I’m coding solid. Fourteen hours a day – with a few days out for “good behavior” or necessity. 
As you know I did not release. I kept plowing on. Near enough was not good enough.
It’s true the product “worked”, but there were banshees under the hood that for the months that followed would continue to threaten escape if I released the software, until I made an abrupt and arguably perilous change in direction to banish them.
In some respects, I admit, I tend to be a little to much of a perfectionist, a neat-nut and a egotist. I can’t help that, it’s my nature, but I do try to analyze it and keep the knowledge foremost in my mind.
That knowledge is this. I code UI elements like a magpie collects shiny trinkets. It’s almost a psychotic addiction.
For me a piece of software is more than just the code, a basic UI and a job done for the user. For me it’s an experience. It must empower and it must feel right. But it must be more than “right” it’s got to make the person using it feel like they can and want to do more – and feel proud of what they did.
When people look at my software I’m forever disappointed because of this. I set myself up for an emotional fall. I point out a widget or UI element that took hours or days of coding or design to get their impression and nearly always get a “yeah – it’s nice.” There is nothing unique to me in this experience, I’m sure we all get it,
Such is the life of the developer. Get it wrong and they’ll not be short in telling you. Get it right and you’ll probably never be told a thing. Even though most of us get most things utterly wrong in this respect – it’s a dilemma that few take the time to analyze. Maybe it’s the reason most mISV’s and a good proportion of ISV’s don’t pay heavy attention to UI – particularly on Windows?
Linux application developers are exempt in this equation. It seems UI rarely gets any attention to detail on that platform.
I Coded On.
It’s been, since June 1st 2008 146 work days. Average of 15 hours each day. A total of 2044 man hours.
MixAction has not been released at the date of writing.
I spent much of this time writing bug fixes for a poor implementation of COM that my compiler handed me.
It wasn’t the audio library, I tested the results in C++ and VB 6 and both returned correct values. Delphi did not – at least no consistently and nearly always a different value. I then discovered that COM has been broken with no intention to repair it in Delphi since version 4 (despite years of requests to attend to it by several COM based solution providers). In short, I was screwed on this one. I could of course hand code DirectX and implement the solution that way – throwing away a grand of investment in an excellent audio API and release sometime in 2012. Or I could ship warts and all and hope nobody noticed.
Not bloody likely
When you are fighting with a compiler and it’s associated primary libraries on something that is fundamental to the core of your own application you are, in effect, building a house – of cards.
With a great deal of hesitation, deep consideration and a healthy dose of fear I moved IDE’s and began to embrace the .Net framework after signing up with BizSpark from Microsoft.
Not everything is perfect on .Net. I’d be an idiot to make that statement. But my application core – the audio engine (or engines as in this case) – is now solid. No more calls to COM coming back weird and not wonderful. No call to COM and getting 7, 11, 57 or 1098 back in a call to an OLE_Bool (I exaggerate not).
There Were Other Gains
While my domain knowledge is reasonably good I managed to amass more information from the “horses mouth”. Beta testers, other developers and my own new experiences. The nature of how the product worked, it’s assumptions in some respects, evolved for the better.
Under .Net Reflection became a prize unattainable without enormous pain in Delphi. I will expand on this in the coming weeks.
Suffice to say for now – true separation of the audio from the GUI, a vital design for this product, has now been fully achieved without pain and best of all it’s native to the application. Clean, neat and tidy. What else could a neat nut want?
There are other major changes that I’ll document as begin to move now towards a finished product. Database decisions, which one, should I use one at all and other decisions I’ve made.
One thing is for sure. November saw me embrace something new, something I was accused of as seeing as “Oooh – What’s this new shiny thing” on the Business of Software forum. That new has meant that while November saw me head down and bum up inside a new IDE learning new tricks out of necessity, that particular 30 days just past in November has paid dividends.
MixAction will not be released in 2008. It will be released in 2009 and the first release will be a simple implementation on the surface. But through a variety of tools and technologies iterative enhancement after release is now possible without breaking anything fundamental, at least until a Version 2+ release.
I expect, when I release, for a bunch of folks to declare “what was all the fuss about” and in a sense that’s the beauty of it. What’s underneath now gives me flexibility to implement features in the future with more precision and assurance.
I wanted a product that could grow comfortably, that, through iterative development, would please customers through the power of “new things”. I wanted something that would take the playing field the product will exist in and break the paradigms. There are existing competitors (beyond that nut who attempted to clone) that I want to try to play catch up with me, ultimately, and not the other way around.
Business, like politics, is a game. A deadly serious game without question. Akin to chess. I do not see software development and the business of software like fishing, or farming or the other analogies so often used. It’s chess. A new product, to my mind, should be a reckoning – not an attempt to harvest in Autumn by hoping it will rain this Spring.
Scott Kane
