Development guidelines (How to improve software quality)

Most programs begin as small somethings growing over the time as requests get more and more. Often programs then get quickly a big something with a lot of strange side effects. The programmer begins to worry each time he touches the software.

With some discipline you can keep your software tidy and increase the life cycle of your code pieces. It will improve your software products if you keep in mind the following tips:

1. Encapsulate multiple code lines in functions. Do not work with copy and paste of code lines. Create subroutines for every code parts that are used more than once (except performance critical code parts). If there is a bug to fix or some enhancement to do then the change should be required to make only at one place in your code as far as possible.
2. Think in objects and components. Create objects and attach the appropriate methods to them. Use encapsulating of objects and components. You should think everything as a component not as a single program that is only used for itself.
3. Use Interfaces. Make interface definitions for your main business objects so that you can easily load them from somewhere, save them to somewhere or handle them however. Interfaces should be accessible and reusable as programming components (ActiveX, CORBA etc.) as well as exportable and importable via simple text files. See also IOD (Interface Object Development).
4. Extract language resource strings from your code. Language specific messages or text strings should be read from a resource file. With the appropriate implementation one only need to translate the resource (text) file for providing your software in another language.
5. Use configuration programs and configuration files. To keep your software flexible you should allow as much configuration as possible. Whenever you are thinking about a decision to be done in behaviour (e.g. delete some files you worked on afterwards or not) then do not hesitate to implement an option so that the user or an administrator can choose the desired behaviour.
6. Expect future enhancements - Keep your software open. Think forward and try keep you free from limitations as far as possible (operating system, list lengths, etc.). For example do not use fix dimensioned arrays that give you limitations of some maximum number. Tend to use objects even if a single property is enough "for the moment".
7. Keep your software as common as possible. Support Plugins and Scripting. Avoid to implement very customer specific special procedures. Prefer to allow the integration of PlugIns and Scripts and keep your software slim. Add Plugins and Scripting everywhere where there may be need to perform particular business logic, specific data export or import and integration to other software products.
8. Write Documentation and comment your code. It is a very good thing to have documentation because you can be sure that you don't have an idea of a program you didn't touch for some years and then there is need to change something. At least you should write a ReadMe file with the minimum required documentation to configure the software as desired as well as a change log with at least Version number, Date and Time and a list of changes (probably with prefixes like FIX:, ENH:, CHG: to give an idea if something is a bugfix, an enhancement or some other change that may result in a changed behaviour). Don't write long documentations of something that is clear - concentrate on the specialities someone has to pay attention.
9. Design your software easy/intuitive to use and to configure. People usually do not invest a lot of time in evaluating software. They also tend not to read lots of documentation. Your software must be intuitive to use and to configure as it either might be that your program is used only once a year and nobody remembers complicated procedures required to operate your program correctly.
10. Be compatible with older versions of your software. When you update or change your piece of software there should not be incompatibility with older configuration files and the new version should work with the old configuration file the same way as your software did before (besides bug fixes) - talking about enhancements. But compatibility does not stop here. Compatibility should be given for components itself (e.g. use binary compatibility for ActiveX components).
11. Keep your messages short. People hate reading. So whenever you need to pop up with a message keep the text short.
12. Keep it simple. Don't overcomplicate the GUI and your algorithms. Use the KISS principle.