The Recursive ISV

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

Pretty much spent the whole day writing the help file documentation today.  More on that in a moment.

Yesterday I declared a code freeze.  However today I became aware of a little bug that was cosmetically annoying.

MixAction has a little indicator arrow in the playlist, similar to how iTunes does, showing the currently playing track.  Under certain conditions this indicator gets saved to the meta file for the playlist and ends up showing each time that playlist is played until that certain condition raises it’s head again.  Undesirable.  Or so I thought…

Then it occurred to me that this could actually be a neat feature.  Power goes out or program closed accidentally somehow in a performance?  No worries.  MixAction remembers the track you were playing even if you don’t.  Added some code to make sure it resets properly if there is no interruption but let it show the indicator if that condition isn’t met.  So a bug, albeit a cosmetic one, ended up being a feature. 

OK.  The help file.  I don’t know about you but for me writing a help file is kind of like having each toe nail extracted without anesthetic and then the perpetrator moving to each finger on each hand.   Deliriously painful. 

So I got around half way through today and I’ve ground to a stop now.  I’ve also been working on the website, so it’s not like I had my head in the help compiler WYSIWYG tool all day, it just feels that way.

What this means is that tomorrow I’ll have to stick my head back into it and complete the job.  But hope is in sight as the hardest of it is completed now, though it will require massive expansion and tweaking at a later date.

Sue from Alta WebWorks completed my website template and It’s looking beautiful.  Now I’ve got to write the content.  But before I get to far with that I want to re-read Bob Walsh’s ISV e-book to try and make things as sharp as possible.

Uploaded 100 serials to start FastSpring off with for order fulfillment last night.  Enough to get things started in that respect.

I have identified a few issues I need to bug fix before handing off to the testers and I’m sure there are a few I’ve not spotted.

At the end of the 30 Days I intend to write an article here that summarizes some of the issues I’ve bumped into.  Decisions I’ve made that worked and the many that either did not or I wish I had done differently. 

Believe it or not I have a bunch of things to add to the project after release that were either pulled during the 30 Days due to time or were a direct result of either making an earlier decision in respect of something else.  Plus I’m making some features part of the sales strategy and will not be putting the code for those in the trial version at all.

I’ll also be talking about scope in respect of taking on a relatively complex application, though at the same time relatively small feature set, in a period of 30 Days.  Even with a heck of a lot of stuff prepared nothing prepares you for doing what all of us have been doing this last 30 Days.  I’ve worked as a corporate developer, project lead, department manager and private consultant and everything in between.  But the 30 Day lead time we put ourselves into is one of the hardest I’ve ever done - if not the hardest.

And I’ve loved every minute of it. 

Later…

Quote of the day:
All paid jobs absorb and degrade the mind. - Aristotle

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