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.
Sounds simple but there is a lot more to it than that.
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?