micro isv, misv,isv

Day 45 - 30 Days, The Road To Banality?

25 07 2008

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

It’s been quite a few days (six in fact) since I’ve managed to get a few moments to write.  In that six days a hell of a lot has happened.  Nothing bad as such, but not entirely all good news either.

First up - I’ve been staying with the wife and kids.  For me a bit of a holiday away from all things development and business.  I’m usually very bad about doing this, but this time I was delighted. In fact elated, as I shall discuss further on.

The bad was that the reason I was away was so that my wife could be available for her mother, and out of interest and concern herself, as her father, 76, had open heart surgery.  We visited him, attended my youngest daughters biannual school concert (ah, another use for MixAction) and of course the more mundane (but none the less lots of fun!) looking after the kids while my wife did all the things she needed to do.  Which worked out perfect, especially given the youngest ended up with a serious asthma attack on Wednesday and Thursday after her concert (the excitement) which meant I was there during the day while my wife was out. 

Family time is great.  My wife’s father is doing well, or at least as well so far as one can reasonably expect after such a massive operation, and I’m now back on deck.

It also gave me time to give considerable thought to MixAction, our company, my goals, design and implementation models, code implementation and management - and probably most cathectic for me was a post last week on a blog owned by Ian Landsman who wrote:

“All the rage the last year or so seems to be trying to build an application as fast as possible. The common length of time seems to be 30 days, but it sometimes goes down as low as 7 or even 5. While this may be an interesting idea as a publicity stunt for an established company or for a Google engineer using their 20% time it’s about the worst idea a would be MicroISV can take up. In fact, I can’t think of a better way to ensure failure in a software venture (a venture you hope to replace your full time job with).
I assume this has come about from the new mantra of release early and often. Those ideas may be good ones, but for a one man show putting an arbitrary limit on the development of your product is suicide.”

OK.  I commented on his blog at that time, but what he wrote (and his article is well worth reading) is not at all incorrect.  In fact I’m going to do something totally unexpected here.  I’m going to sweep aside the mental castration of testosterone and ego (and it’s remarkable how intertwined the two are) and state he is right on the money!

I only disagree with the headline of his article, and my reasons are outlined there in my responses to him. 

10101875A~Jack-Nicholson-The-Shining-Posters

So how was it cathectic? 

The old cerebral matter has been mulling over exactly what I had at this juncture.  In the whiplash of the 30 Days, which I do not regret one iota, I failed in making sense of the bigger picture and that is suicide!!

To pull this off you have to sit back and put on your analysts hat.  That’s probably hard if you’ve never done professional analysis, but it’s vital. I have and the penny dropped.

I did not have a release candidate.  I had an incredibly well scoped and implemented prototype!

You’d think this would make me feel incredibly sick.  The realization; “Oh the shame of it!”.  Far from it.  In fact it was, as I’ve said, cathectic.  It was a tension release, it felt pretty bloody good, mate, and I’m in debt to Ian Landsman and Steph (who’s written a rather nice book that I’m reading, and will blog about in the future, on SEO) for giving me a bloody good wake-up call!

So.  With that under my belt I started thinking about some of the issues my testers faced, some of the issues I’m aware of that nobody else has discovered and what I want to see now. 

I don’t want just another “clickware” application.  My competitor already has that covered (well, kind of, presently his public build fails to run as he forgot to include some proprietary files that I suspect only exist on his system.  It’s been six weeks now since his new release and he’s not fixed it, which indicates the level of turnover he’s doing, or not doing, and is a perfect illustration of If You Don’t Love It Don’t Release It that I wrote about some months back).

My competitors program is a 30 Day job.  OK, that’s stretching it, it’s a one week job for a competent coder including writing the doc’s and installer.  I’m serious.  He’s a hobbyist.  His interest is clearly Theatre.  I’m a programmer who’s worked in Theatre and has Audio engineering certification.  That’s a critical difference.  Ethics prevent me from including a screenshot or a link for comparison. 

He’s built a product, I’m building a company, even if it will be a small one.  That is equally significant as a difference.

What he’s done is not what I wanted.  Been there, done that, I have the tee-shirt. 

So.  Mixerlicious,   stays on hold.  MixAction goes back into full development.  In June I switched API’s, switched file formats, hacked at the source code of a commercial library I purchased because it didn’t deliver in the way I wanted (that’s not a criticism of NextGrid, it’s a nice component, but I’m clearly asking it to do things it was never intended to do) and more last minute shifts in internal implementation than you can shake a woomera at.  The Audio API is luscious - and it’s not being taken advantage of fully by me presently.  That’s got to change.

Like I said, a great prototype.  I achieved most of my goals. 

  • Making something complex into something easy to use.
  • Breaking metaphors because those metaphors fail in software.  They make sense in the real world, but bugger up in software.
  • Taking domain knowledge and applying it solving a problem. 

Now it’s time to do it right.  Frankly I don’t care if it takes 30, 60, 90, 120 or 360 days.

Neither should you with your product.

So in summary.  For a complex product and a view towards building an mISV with any hope of progressing to ISV (or even remaining small, but maintaining sales you can live off) 30 Days is great for a prototype. 

It’s fantastic for some free PR (this blog is being linked to from Theatrical sites with zero effort from me, making it very worthwhile to date), and it does make for a great splash and getting folks to drop by.  BUT…

If you don’t love it, and I don’t think you can love it after 30 Days intensive coding, in fact you’ll come to loathe it in many instances and will need the time to step back and analyze - then DO NOT RELEASE IT!

This is not the last word on the development of MixAction, or any of the products and the company I’m building.  There is no point in making mistakes in life if you don’t put them somewhere safe to take and out use when you need them most.

Make lot’s of mistakes - they’re your best friends in life and critical experiences in business!

Scott Kane

PS.  BTW - any resemblance to me and Jack Nicholson is purely coincidental…  ;-)

Quote of the day:
When a thing ceases to be a subject of controversy, it ceases to be a subject of interest. - William Hazlitt

Please Consider Rating This Post
Rating: 0.0/5 (0 votes cast)
Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Live
  • Slashdot
  • StumbleUpon
  • Technorati
  • YahooMyWeb
  • blogmarks
  • BlogMemes
  • Blogosphere News
  • De.lirio.us
  • E-mail this story to a friend!
  • Internetmedia
  • LinkedIn
  • NewsVine
  • Reddit
mISV Release In 30 Days Or Bust Trying...The Colonel, Secret Recipes,11 Herbs and Spices...Day 14/15 Half Way To The 30 Days...Day 41 - The RC Waiting Game...

Related posts brought to you by Yet Another Related Posts Plugin.


Actions

Information

4 responses to “Day 45 - 30 Days, The Road To Banality?”

25 07 2008
Phillip Flroes (22:18:52) :

Scott,

I think the 30-day thingy was a good exercise at least it got the procrastianation out of the way. To be able to release a really polished product at the end of that period was a nice to have but it was not the be all and end all of things. A prototype as the end product? Maybe. To really get everything in place will really require more than 30-days especially if you’re the only one doing it. In my case, I’m still tweaking the code here and there; polishing the UI interface bits as well as the db backend. It’s sometimes frustrating and like you, I want this product to be the foundation of something that will hopefully be really fruitful for myself and the family.

On another note, where are you exactly in Vic? Good luck and may you succeed!

Rating: 0.0/5 (0 votes cast)
25 07 2008
Scott Kane (22:31:27) :

Hi Phillip,
Yep. Agreed. It’s a tough call too, but the right one I think. The great thing is I won’t be adding features now. For the first version I have them set in stone, so to speak. But it gives me a shot at working things up so that subsequent releases (and extra versions) will benefit from a solid underpinning upon which to more easily add the new stuff.

Best of luck with your effort too, I’m hoping fellow 30 Day folks don’t read this post of mine as disparaging, it’s not supposed to. But being pragmatic is a necessary thing.

I’m in Melbourne, out in Hurstbridge, that’s out Greensborough way if you know it. :-)

Rating: 0.0/5 (0 votes cast)
26 07 2008
Ian Landsman (00:29:17) :

Great post Scott! I think you’re coming around on huge lessons which will be very important to you down the road.

1. This one you’ve got, that you can’t really put a time limit on these things. It’s done when it’s done, you can try to do it quickly, but setting arbitrary (and extremely short) dates on it is likely to hurt you more than help. There are some upsides as you mention and those are great, but in the end you still need to make sure you produce a good product.

2. This one is something people don’t realize and don’t plan for. Life goes on even though you’re starting an mISV. Family get sick, kids have events, “stuff” happens. Unlike a larger company there’s no one to pick up the slack for you. When “stuff” happens to you, every minute of it comes directly out of your development time and stuff will happen.

Flexibility and the ability to admit you’re wrong is also very important. It reminds me of when I started HelpSpot. I had put in several weeks of coding an a customer management area. I didn’t really want it as I didn’t want to be a CRM, but all the other tools had it so I felt like I needed it. It created all types of issues with synchronization with customers real data system and was a huge pain.

Then it hit me one day that I’d be much better off building a simply api that let customers integrate with their real customer data systems (ldap, etc) rather than build my own. So I went and ripped out all that code. It was the best decision I ever made and the api is now one of HelpSpot’s unique and key features.

Without being flexible and being willing to lose a little time I would have left all that in and it would have been a big mistake.

Rating: 0.0/5 (0 votes cast)
26 07 2008
Scott Kane (13:12:27) :

Hey Ian!

Glad you dropped by and commented. I do concur 100%. I rather thought you might be surprised to read this blog post here. :-)

I have sweeping changes to make in places only I can see. But they affect future extensibility. Breaking them now will save huge pain for my customers (and that translates to less work and pain for me too) later.

Rating: 0.0/5 (0 votes cast)

Leave a comment

You can use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>