General Software Development

Development in a commerical environment

Software development should only ever be done to improve or automate an existing process, or to do something of value which can't be done without a computerised system. Transferring a manual process to a computer system is not always the best option, and if done badly and without thought and analysis can actually cause things to be worse.

Software development can, if done correctly, acheive major cost savings by reducing a manual process, or even sometimes eliminating a manual process. If done correctly it can give you a competitive edge, allow you to see all the information you need to make business decisions, and reduce labour costs. If done badly it can create an administrative nightmare or worse.

Considering developing a system

• What are your requirements?
• Do these requirements fit in with an existing off the shelf system?
• If not, are they similar, or is it possible to customize an existing system?
• Have you considered support and hardware costs?
• Have you considered using open source software, if something similar is available?
• Perform a costs / benefit analysis before developing or purchasing.
  There's little point in developing or purchasing a system if it won't pay for itself

Developing a system

• First and foremost, make sure you know what the basic requirements are for your system
  Most systems evolve over time, but it's important that everyone involves know's what you're trying to acheive.
• Keep the eventual users involved
  There's nothing worse than releasing a system and realising that it's unusable. Prototyping and alpha / beta releases are a great way of making sure systems are going as planned. Remember that the your users also have jobs to do though, it's better to book some time with them and go through some real life examples than to just dump some software on them.
• Document your system workings
  All but the simplest systems need some kind of documentation. As a minimum level of documentation, the purpose and requirements of the system, complicated processes should be broken down into simple actions, database table relationships should also be documented. Also, if there are multiple applications in a system, make sure all relationships between the systems are documented - if you don't you're asking for trouble. UML is a good analysis and requirements gathering process, if used flexibly.
• Make sure it works before releasing it
  If things go wrong when you release something, it's generally far more difficult to fix than in testing stage. Quite often the problem will also be compounded because users are using your system live, therefore causing the faults to propagate themselves.
• Make your system flexible
  Businesses change quickly, make your system as flexible as possible within the timescales specified. If it's easy to make something configurable, and it's likely to need to change, it's generally worth doing even if it's only storing a configurable value in a database. It's easier updating a database table than modifying an application (especially for large client applications). Make sure you document these configuration options, and tell whoever is testing the application about them!