The AuditShark Challenge Results? FAIL… Sort of

Well, I made no secret of the fact that I wanted to launch AuditShark by the end of June. The end of June was a few days ago, so you might think I’ve failed to meet my goal pretty miserably. Except that in May I stated on my podcast that I was pushing back the deadline by about a month due to all of the work involved with getting MicroConf off the ground. In addition, I quantified it a bit better by stating that I was intending to get to Alpha. So I missed it, but I also knew that was going to happen so it’s hard to say how that should be classified. I predicted my failure accurately I guess? Not sure how to score that one.

I think my initial goal of getting it completely launched was probably unrealistic. But the fact remains that I still want to get to Alpha by the end of this month. and the end of July is bearing down on me fast. I’ve got a lot of work ahead of me if I intend to get AuditShark into some Alpha testers hands before the end of the month. After it hits Alpha, I’ll be focusing a lot more efforts on the marketing behind the product too. That way I can work on bug fixes in parallel with the marketing efforts. Part of the reason for doing that is that it’s so difficult to know how much longer it’s going to take to get finished because some of the features just haven’t been scoped out yet.

Since programmers are notoriously terrible at estimating how long things will take… don’t say we’re not because we suck at it. How many times have you said something should only take 10-15 minutes and it takes three hours because there are all these other dependencies that you hadn’t considered before you got started? Yea, that’s what I thought…. and since we’re terrible at estimating how long things will take, it’s a lot easier to make those judgments as you start working on things. And if there are better ways to do something which will take a lot longer to complete, I’ve been taking shortcuts to hit my deadline and then logging the additional functionality as a bug or feature request. It’s been working out pretty well so far, but my list of things to implement has grown to well over 100 items. At this rate, I’ll be done in 2038 which is just in time for the Unix Millenium Bug.

Another reason this product has been in development for a long time is because there are soooo many moving parts. My Visual Studio solution has ten separate project files in it. TEN! That’s a ridiculous undertaking for a one person product. But it’s gonna rock like a rockstar when it’s done!

I’d write more about what’s going on, but hey… I’ve got work to do. 🙂


  1. Robert Graham on August 29, 2011 at 7:54 pm

    Don’t set goals you know you won’t reach. It’s not good for progress. It makes you lazy in attempting future goals that may be achievable. You always get better at whatever you are practicing. Sometimes this effect is subtle. Don’t get better at missing goals on purpose.

  2. Mike Taber on August 29, 2011 at 8:07 pm

    I don’t think I was intentionally trying to fall short. Merely that in retrospect, my goal was perhaps unrealistic given the other things that I had going on. I wouldn’t say that I miss goals all the time, but I don’t think that it deters me from setting aggressive goals in the future. I think the key part of setting goals is that you have the mindset that although they may be aggressive, they’re achievable given the information you have. But if you don’t meet those goals, that’s no reason to beat yourself up over it and give up. You have to keep plodding forward and setting goals is a tool to help you do that. When you start intentionally missing goals, you’re counteracting the purpose of setting goals in the first place and that’s what I think is counterproductive.

  3. Matthew Paulson on November 20, 2011 at 11:34 pm

    So, it’s 3 months since you’ve posted. Do you have any paying customers yet?!

  4. Mike Taber on November 21, 2011 at 1:09 am

    Not yet, but I’m so close to launching that it hurts. I’m trying to set up meetings with prospective clients this week to do some demos of the software and show them what it can do for them. If they’re willing to give it a try, I’m willing to install it and work through any of the initial issues with them.

    There are still some features I’d like to implement, but most can wait. And since it’s a SaaS app, I can roll them out whenever I get around to it.

    At the end of the day, if I’m able to have the product publicly launched rather than in a private beta by December 31st, I’ll be extremely pleased. Paying customers is obviously another story, but that will come with time.

Leave a Reply