Egn Systems main content
 

The Key to Successful Custom Software Development

Listen and understand

Very often there is an overwhelming desire on the part of the software developer to start building and delivering as quickly as possible. Whilst this may be a worthy intention, it means that the most critical part of the whole project, understanding the requirements, is not always given the attention that it needs. My approach to new projects is to spend as much time as I feel it takes listening to the client. My aim is fourfold:

  1. Understand the predicament and requirements.
  2. Be sure that a bespoke solution is the right way to go.
  3. Appreciate the levels of expertise (business and systems) of the users.
  4. Be aware of the timescales, urgency levels and budgetary constraints.

Of course commercial reality dictates that this process cannot continue indefinitely. But the extra time and effort spent at the outset will certainly pay dividends further down the line.

Inform

It is vital to keep the client informed and involved at every step of the project. Feedback is invaluable. I have found that not only does this approach head off problems at a later stage, it also reduces the learning curve for the client and stimulates new thinking.

Information can take many forms – design specifications, prototype development, progress reports, demos, testing updates, regular meetings and training sessions – to name but a few.

Make it user friendly

The importance of a user-friendly, intuitive system cannot be overstated. They key point here is for the software developer to understand that what is obvious to the developer may not be obvious to the user. It’s a matter of perspective – the user sees the world differently.

He/she will not appreciate the technical wizardry that makes up the system and will want to be protected from it. To the user the system should be simple, straightforward and efficient. The system should guide the user through the required processes and not leave him/her faced with a bewildering array of choices.

Needless to say, it should be fast. But if it cannot be fast, it should at least let the user know that something is going on and display some sort of activity (e.g. a progress bar).

If the system produces detailed output, then there should be audit trails to enable the user to analyse and prove the output.

Test it, re-test it and test it again

Meeting the client’s requirements and making the system user friendly are only going to be worthwhile if the system actually works. My objective in testing is not see if something works, but to prove that it does not work. When I have failed, I am happy!

I take the view that users will not always use the system in the way for which it was intended. In any event, it should withstand whatever is thrown at it. So I test with invalid data, illogical data, missing data and, of course, valid data. I test at three levels:

  1. Unit - the individual program.
  2. Module - the overall processing to which the program belongs.
  3. System - the whole system.

And I would vigorously encourage user testing, even if it means a degree of hand-holding.