Designing a Program

There are a lot of things you need to consider when designing a program or application. It isn't just as simple as this gets entered and that gets run. If it were that simple then very complex programs could be built in a very short time. They would work provided that the correct values are entered in every spot they need to be and would fail disastrously for the simplest typo.

With any process a significant fraction of the code (usually more than half and perhaps as much as 90%) will be concerned with error checking and exception handling. The more critical the task the more of it will be there to handle when things go wrong.

Let's look at an example of just how complex something that appears relatively straightforward can be. For this example we'll consider what we would need to set up a bPay payment system for handling club membership renewals. For those unfamiliar with this Australian payment system it basically works by you being provided with a biller code that identifies who the payment is to be made to and you generate reference codes that identify each of your customers/members. They make a payment through the bPay system supplying both codes and the money gets deposited to your bank account (as a single payment along with all your other bPay payments processed that day). The bank then sends you a file containing the references and amounts so you know who paid you.

To use this to set up an automated renewal process so that members can use bPay to automatically renew their membership seems at first glance to be relatively straightforward.

  1. You provide each member with their own custom renewal form containing your biller code and their reference (which you also save to match up against when their payment is received).
  2. When you receive the file containing the references you match them back to the members and update their membership data to indicate that they have renewed.
  3. You send a receipt for each payment received.

Sounds simple but there is a lot more to it than that.

  1. What format is the file the bank sends you actually in? Presumably you have to actually set up as a bPay biller with a specific bank to find out as the general queries I have made never provided an answer.
  2. what happens if a file from the bank gets lost? What is their process for resending these files if you don't receive them.
  3. What is the process for acknowledging receipt of the files they send? How else are they to know you never received the file.
  4. What happens if you received the file but the acknowledgement gets lost? Assuming they resend the file because they think you didn't get it, how do you determine that it is a duplicate of a file you have already processed.
  5. What happens if the bank has to return someone's money for whatever reason? What is in the file to advise you of that and how are you going to process it?
  6. What happens if someone pays the wrong amount? If you only process the renewals when the correct money is received then what do you do when someone underpays? What do you do about the extra if someone overpays?
  7. What is the process for advising the bank that you are rejecting payments received where the amount is wrong?
  8. What is the process for you and/or the bank advising the person that their payment has been rejected? Does the bank even have a facility for you to reject payments?
  9. After processing all the renewals, how are you going to reconcile the renewals against the original file received in order to make sure that the file has been fully processed? What are you going to do if the reconciliation fails?

As you can see, even just listing all of the validation/exception processing steps that I have already thought of at that high level means that these validations make up 75% of the processing steps that are already on the list and chances are that if you were to actually develop this system there would be a lot more validation and exception handling steps that need to be added to the list and resolved before the system can be built.

If this process is done properly then when you actually implement your program or application you should never have a situation occur that isn't on your list. Now what you decide to do when those situations occur is another matter. Where something is extremely unlikely to occur and the system isn't handling money then you might just have exception handling in place that simply provides a message to tell you what happens and then have the process stop. That ensures that the rare situations don't provide security holes in your code without you needing to write a huge amount of code to handle something that may never actually happen. You still need to have considered it though in order to make sure you don't leave a security hole. For the example I have used above that would be handling money just failing after producing a message would probably not be appropriate for any of the situations I have listed as that would mean that there could be members who have paid but are not properly recorded as having paid.

From what I have seen of many programs and web applications, their creators have not spent enough time on this step of actually working out all of the possible situations that they need to be able to handle and they end up with situations that their code can't handle. Even situations that initially look like they would be extremely rare can in fact turn out to be common if enough people are using the system. On a tv show about aircraft maintenance problems I was watching, someone on the show made mention of the fact that something that is only likely to occur on one in a million flights is going to occur almost daily as there are roughly a million aircraft flights every day. If such a problem occurred on Facebook then on the day they got a billion people using their site a thousand of them would have been affected by a one in a million problem and so that site needs to consider those as common problems and to look at how to handle things that may only happen once in a trillion times as being likely to affect someone at some point.

Your application may only ever have a few hundred people use it but that just means that a one in a million situation might only occur a few times a year. If your application is expected to last a lot longer than that then you need to consider such things as not all that rare.

How well do you design your programs and applications? Do you have a list of all the unlikely events that you have catered for at least to the point of having exception handling in place to prevent them from being able to be exploited?

go to top

FaceBook Follow
Twitter Follow