Business Software

The first thing to accept is that software development is unpredictable. No matter what new fangled software is implemented and how many function points are estimated, experience has shown that making the target date (let alone achieving the desired quality outcomes), is a hit and miss affair.

Risk may arise due to loosely defined requirements, difficulties in estimating the time and/or resources needed for the software development, dependence on individual skills and rapidly changing requirements due to changing needs.

Here are some thoughts on how to make the unpredictable a little bit more predictable.

Spend more time setting objectives

Project objectives are important. A project should not be initiated without well thought out objectives. Spend time analysing what the project is trying to achieve. The project objectives need to provide guidance to the programmer for every programming task. Pin up the objectives for each programmer to see.

Here is an example of setting an objective. I was asked to analyse the requirements of a busy manager. His manual filing system was constantly in use, and never in order. A system was needed that would maintain the current details, and ensure that records could always be found. That was easy enough. However, during the interview, the phone rang constantly, with requests for information. The objective finally agreed on was “Eliminate the phone requests”. This led to a very successful solution, but completely different to that originally envisaged.

Having set the objectives of the project, do an exhaustive analysis of how the objectives can be achieved. This should eliminate unrealistic objectives – like “The best and nicest and cheapest and quickest”.

Do not spend too much time gathering requirements.

Rigid analysis stifles programmer and user creativity. It is also no guarantee against a software disaster. Where the documentation of the requirements runs into several volumes, it usually guarantees a software disaster.

Users frequently do not know what they want, but they will recognise it when they see it! What was the original requirement may not be what was wanted at all. Rather spend time on creating a solid project framework that will enable you to achieve the major objectives.

Break a project into multiple tasks.

Wherever possible, a large project should be broken into smaller tasks. Each task will then be more predictable with less to do and less that can go wrong.

The initial programming task should be to create a framework with minimal functionality. Create dummy procedures to show the style and the intent – it is important for the users to see the “look and feel” of the project early in the development cycle. It is equally important for the users to get involved right from the start. What you want is users to start “owning” the project.

With the project objectives soundly set, the basic functionality should be subject to little change. The dummy procedures can be completed once the project concepts and design have been approved. Later tasks can then add the “bells and whistles”.

The project must be “infinitely modifiable”.

The project must be designed so that it can handle major changes to requirements. With a soundly defined framework and infinitely modifiable design, the effect of users changing their minds will be minimal. As will the consequences of new or better ideas as the project evolves.

There needs to extensive thought on how an “infinitely modifiable” system can be created. This must be done before any programming is initiated. “Top down”, modular design standards will help.

The consequences of having a rigid system are unpleasant. When change occurs, and it will, you will have very unhappy management when the target date needs to be extended. Equally unpleasant is to send the programmers on a “death march” to get the project finished on time.

Do not use new or complex technology

Using straightforward, tried and trusted Software provides a head start. There is always some advantage in using the latest version of software – but there can also be a heavy cost. If new technology is essential for the project, then an independent trial of the software is needed to ensure adequate technical knowledge and that all the software bugs have been ironed out (are they ever?).

Relying on immature software with limited programmer exposure to the software is a recipe for disaster.

Hire only the best and brightest

The success of a software project is mainly dependent upon the abilities of the developers. They determine, more than any other factor, the viability of a project and have a tremendous influence on productivity.

A few tips: The successful applicant should have a keen sense of humour (see De Bono and Lateral Thinking) and a good grasp of idiomatic English. Excellent communication is all important.

Do not proceed with a large project where the best and brightest have recently left the company. The company will be suffering from the “skim milk” syndrome – and you need the cream of the crop for successful development.

Reusable code

It is always productive to collect a large library of reusable code. The procedures should be used to standardise: error handling, database access, edit routines, grid handling, etc. The reusable code will reduce debugging times, as each procedure will be called multiple times. It also lessens the amount of coding needed.

By: Neville Silverman