Sign in to follow this  

Checklist for end of dev. cycle

Recommended Posts

I am getting close to releasing what will be my first major foray into the world of commercial programming, and I needed to know what some things that I can do to make sure that my program will run flawlessly enough so that people who pay for it will not feel jipped the moment they buy it. I got a decent sized beta pool for the beta release, I just need to know some things that I can do to make sure it all works. Things like tricks to remember when building an install file, (I am using C# for this project) So what are some things that make commercial c# apps "feel" professional rather than just like a hobby project. I know these are very general questions, but I am really kinda nervous because as I said, I don't want anyone to feel ripped off or give myself a bad name out there on the market. Thanks for any info in advance! [EDIT] Dun isn't a word! hehe. [Edited by - neonic on November 25, 2007 6:31:08 AM]

Share this post

Link to post
Share on other sites
Just some things off the top of my head, by no means a comprehensive list:

  • Make sure you have a full installer and uninstaller, preferably as compact and simple as possible. For example, skip things like EULA screens, rebooting, etc. if you don't really need them. A functional uninstaller that fully removes the software is mandatory as well.

  • Obviously doing some hefty bug testing is good. If possible, line up some people who've never used your software, and watch them use it. Pay attention to where they get stuck or have questions; those are trouble spots that you may want to refine or rework.

  • Since you're using C#, make sure you handle the .Net packages you need in a simple and easy way. Unfortunately I haven't deployed any .Net software commercially, so I can't offer any particular tips here; just make sure people don't have to go download .Net themselves or anything hideous like that.

  • Have someone proofread everything for spelling and grammar. Ensure you use consistent terminology all through your program (if you call it a "widget" in one place, for the love of all things holy, do not call it a "sprocket" somewhere else). Check that your graphics (if any) look good on a variety of monitors and resolutions - that's a big mistake that a lot of hobbyists make. If applicable, get a real artist to do logos and other shiny pictures, so you aren't shipping "programmer art."

  • And last but definitely not least, if anyone raises any complaints or objections during your beta, think about them carefully. There will be cases where people want to use the software in a way you haven't thought about; you need to take each case and decide how best to handle it.

That ought to keep you busy for a while [smile]

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this