Production Ready Code / Product Requirements

Question

What are the things that we need to ensure before a software goes alive. I assume that the software is a commercial product. But most of them applies to OSS as well.

I made it community wiki so feel free to update the question and the list.

If we treat this as a check list, So far I've come up with these:

Code Related

• Exception Management, Proper Logging and Error Reporting are in place
• Ensure that Licensing Solution is in place (if required)
• Code is Obfuscated (if required)
• Get rid of all unrequired code (not referenced function, old code, etc.)
• Ensure that there is no unrequired DLLs in the installer (such unit testing DLLs )
• Compiled without debug symbols
• There is no hardcoded test stuff in the code

Test Related

• Test the installer / uninstaller
• Test the application in different OSes
• Test most common usages of the application
• Software License and dependant library licenses are deployed with the installer
• Works fine in different resolutions

Product Related

• A Website
• Help / Documentation
• Online Bug Reporting / Tracking facility for users
• No typo in the GUI or in the documentation

Other (suggested by @RN)

• Backward compatibility
• Integration with other products
• Data/Configuration migration to the newer version

I don't know if there is point of starting bounty in community wiki question but nevertheless I did. I hope this will attract more answers.

Answer 1

Backward compatibility

Integration with other products

Data \configuration migration to the newer version

-I have mostly enterprise applications in mind when I mentioned the above (Not sure if you were seeing answers or additions to the question as a wiki. )

Answer 2

1. Stress tests - make sure the product (if it isn't standalone), the website and any other services (such as license servers) can all cope with any 'surge' in use from day one.
2. Make sure that a customer service/support team (or process) is in place, and again is ready to deal with the initial surge in demand.
3. Provide a download service for any additional items and/or patches that the user might need (look into signing 'official' executables).
4. Make sure there is a tight version control/configuration management process in place and make it easy for the customer to find out what version of the product they have, what they need and what the differences are between versions.
5. Provide a demo/trial version of the product.
6. Consider providing (and maintaining/moderating) community support e.g. customer forums.
7. Make sure that the product, website, download service, license server, etc are all properly secured.

Answer 3

In no particular order:

1. Check install with shared dependencies already installed
2. If Windows, check installing and running on machine without a 'C:/' drive
3. Check installing as users with and without admin rights
4. Check running as user with and without necessary permissions
5. Check running as two users logged into the same machien at the same time
6. Check install with other version of installed dependencies already installed
7. Ensure documentation, help, demos, etc. are up to date
8. Ensure code is in source control and backed up (you really don't want to lose it after shipping)
9. Delete config files and check still works (Recovers or warns appropriately)
10. Delete data files and check still works (Recovers or warns appropriately)
11. Delete other dependencies and check still works (Recovers or warns appropriately)
12. Test performance with very large data sets
13. Ensure that all tests (you are using automated tests right?) pass
14. Check installing and running with different regional settings
15. Check handling of multiple character sets
16. Check works for users other than the one who installed (if appropriate)
17. Check works on different screen sizes
18. Check works on different screen DPI and/or with Large Fonts
19. Check works with assistive tools (magnifiers, screen readers, etc.)
20. (In Windows) check works with roaming user profiles

Answer 4

Make sure you've labelled your source code so you can recreate the release again and get it backed up.

Ensure you've got a set of debug symbols saved so if you get a crash reported by a customer and they can supply you with a crash dump you have some chance of analysing where the problem occurred.

Answer 5

Ensure you're geared up for receiving support calls/emails and have some process and policy for responding to them.

Will you give customers individual fixes/patches, or will they have to wait for a service release. Or if it's web-based, when will you make updates.

Answer 6

1. Test the performance of the application in terms of responsiveness
2. Test under different scenarios -- for instance test with Vista and Windows 7 with UAC on
3. Ensure the support staff is up to date on the software and adequately trained
4. Have some sort of issue tracking system in place for the support team

Answer 7

Check what went wrong with previous releases, and make sure it doesn't happen again.

The checklist seems longish. Software can go live with a long list of incredible flaws and still be a success. Perfecting a release is not always the best use of your time.

Answer 8

Check hidden potential problem running a memory checker (purify/valgrind/boundschecker or whatever)

Answer 9

No mention of ensuring that all code is written using secure coding practices, with proper encryption, no backdoors or other weaknesses.

Answer 10

The single biggest item you need to "have" for production code is to ensure that regardless of the application errors, the user's data remains consistant.

Having a beautiful application that performs under stress, installs properly and is well documented etc is pointless if the first time the app encounters an error it totally screws the db...

Answer 11

Make sure you have compiled your version in release mode if you are creating the .NET application. Also check your web.config that you disabled debug=false,trace enable=false.

This are small things but will affect the performance. Also if possible use percompiled version of code that will increase performance of your application.

Answer 12

A requirements list is really a list of what should we check that might go wrong, and for a large software product, or one that will interface a wide variety of other software and hardware, no amount of forethought will ever be enough.

What is absolutely necessary is to plan for failure, and grow your requirements list organically by having many people use the software and record failure. So what is needed is...

• A method for gathering thorough data (error logging, user feedback)
• A team dedicated and well-trained to sift through problem database and write fixes (there is an endless list of best-practices for this, but I'll say automated testing might be your top concern)
• A "large" test group to verify that updates do not introduce egregious new problems
• A method for delivering updates to the product

This should happen both before and after the product is released, and it should be applied to all aspects of the product (code, media, documentation, website...)

The rest of the requirements should emerge quickly if this framework is in place.

:)