Document Sample

From Concept to Release

By:                Kevin Cherry
Co-Owner:          Timothy Wright
Choose a Concept
• In General
 •       Find a “hole” in the market
     •     Make sure it fills a need that is not already well taken care of by other software
 •       Get inspiration from other projects and technologies you like

 •       Good visual and easy-to-use XNA debugger
 •       Visual Studio’s built-in debugger not suited for games. Very few popular alternatives
 •       Electro’s1 in-game console and .Net reflection2
Decide on a Feature Set
• In General:
 •       Figure out all features initial release will have
 •       Implement simple cases of each to ensure feasibility

• XDT:
 •       v1.0
     •     Basic C# language expressions including literals, object member access, method
           invocation, and some assignment
     •     Basic UI for entering expressions and receiving results
     •     Customizable appearance
     •     Generic, catch-all error messages
     •     Special commands for extra power
Decide on a Feature Set
• XDT:
 •       v1.1
     •     Further support for basic C# expressions
     •     New special commands
     •     Bug fixes
     •     Unit test project
 •       v2.0
     •     More C# expression support
     •     Better parsing system
     •     More accurate error messages
     •     Better UI
     •     More unit tests
• Don’t get carried away and stray from your original concept/feature set
 •   Some deviations are normal, but keep to a minimum

• Get it working first, then optimize
• Try using test-driven, agile, or another form of software development
  that is well known
• Try using well known design patterns where appropriate
• Use a form of version control such as svn or cvs and commit often
• Set a deadline and try to stick to it
• After your feature set is complete, only fix bugs (known as a “feature
• After bug fixing is complete/at a satisfactory level, stop coding for that
  version (known as a “code freeze” 3)
Write Tests
• In General:
 •   Create a set of unit tests and design a way to automate them
 •   Create sufficient tests for every feature
 •   Do not allow a feature to be released if it performs poorly on its tests

• XDT:
 •   v1.1 has 137 unit tests
 •   v2.0 has 478 unit tests
• In General:
 •    Often lacking in other projects
 •    Ensure it is throughout, clear, and organized
 •    Never underestimate the power of good documentation
 •    Allow users to ask questions
     • Forum
     • FAQ
     • Email support

• XDT:
 • Webpage explaining, in detail, how to setup and use
 • Screenshots, sample uses, and a downloadable sample project
 • Downloadable chm document for entire interface
  • Pulls from xml comments found in every type, method, property, and field in code
 • Google group for questions/comments
 • Email given on website
• Make a website with your documentation, downloads, reasons to use
  your project, etc.
• Find ways to announce your project and website online:
 •   Forums
 •   Wikis
 •   Emailing bloggers

• Tell your friends/classmates/co-workers about it
Points to Remember
• Occam’s Razor4
• If you think part of your documentation is unclear, assumes too much
  previous knowledge, overuses acronyms, etc., get feedback and rewrite
• Decide when enough is enough for a particular release
• Your project should be able to be downloaded from a maximum of 3 links
  from your home page. Don’t make users work for it.
• Don’t make your advertisement links bigger than your download links
• Take bug reports seriously and try to offer workarounds until you can fix it
• For open source projects, don’t assume everyone is a programmer and
  has the time to fix your bugs
 •   Asking for help is ok. Expecting it is not.
1. http://msdn.microsoft.com/en-us/library/f7ykdhsy.aspx
2. http://www.evl.uic.edu/rlk/electro/electro.html
3. http://en.wikipedia.org/wiki/Code_freeze
4. http://en.wikipedia.org/wiki/Occam%27s_razor

Shared By: