Two things have [re-]occurred to me as I near releasing my app to beta testing. The first is that - and I certainly learned this last year with the stand-alone Visual Basic application - it makes a lot more sense why so many apps seem half-finished when I start using them. If you had every feature packed in at version 1.0, well, that'd be great, but chances are you've missed more than one deliverable date. Of course stand-alones are much more difficult to manage than an app on "the living web", which you can cobble onto and improve daily, transparent to the client. More on this first point later.

The second thing that hits me again is to be sure you like what you've got before you release. Each change to the application after 1.0 will need to worry about all the things you worried about before plus backwards compatibility. Makes me wish I had that rdbms backend for my app picked out and ready to go now instead of another infamous (and fairly well done) text file kludge. I'm just not sold on hsqldb quite yet.

To expand on the point about leaving out features, in ye olde Digest Handler application there are two omissions right now for version 1.0 that drive me crazy. One is that the app's GUI isn't completely keyboard transversable. Technically it is keyboard transversable short of the multiline text components where you can't tab out of the component back to the other widgets. I'm thinking about cheesing out and just capturing "Shift-tabs" in multiline text components to move focus to the last widget. But to someone who appreciates vi, it's a far cry from perfect right now or even if I add that "fix". The second bit that bugs me is that you can't sort your emails. No way, no how. Right now you get them in the order Digest Handler finds them, which is awfully close to chronological order with most recent at the bottom. I think I'm going to allow people to reverse the sort in version 1.0, but I'd really like to break that open a bit more.

Of course those are just the ones that bug me a lot. QA on user input is pretty sad, as is error reporting to the user. Often bugs are quietly logged in the error file without a peep to the user about what's going on, which is certainly less than ideal. But they don't bother me much. I'm firmly convinced that people are ready to forgive a few quirks to start using an app that addresses a need. Ever used Mozilla? Heck, even the VB IDE? :^)

I've been told that there are two ways to make an "A" on a project. The first is to start as soon as it's assigned and to put the proverbial blood, sweat, and tears into it to make it look polished and professional. The second is to do it overnight and make it look like an "A"-calibre overnight project. The best way to make sure you don't make a quality project is to try and make an overnight project look like the "A" project you would have done had you started weeks before.

To make each feature work just like I'd like would also mean I've practically written a fully-fledged email client, which is not my goal for version 1.0. In this context, the lesson from the paragraph above is to cut out for yourself what you have time to do and do that well. Don't try to make your work look like or act like something it's not. If I want an application that's that much more complicated - let's call it "99.44% complete" - I'll need to plan to invest that time. For now, I want an app that looks like version 1.0 because it is version 1.0 and I'll let the users (if any!) tell me where to start working next.