eli5: Why do bugs in software exist?
In: 0
“bug” can be any unwanted error caused by a non-perfectly written code. They mostly have to do with some small logic-related mechanism.
Let’s say that you need a lil robot to dig a tunnel.
You tell him “if you find dirt ahead of you dig one meter with a shovel” “else, if you find rock, dig 50cm with a pick” “else if you dont find dirt or rock, stop and tell me you completed the tunnel”.
In case it finds clay, since it’s neither dirt nor rock, it will tell you he completed the tunnel, even if it’s not.
There are a million ways a bug can occur, this is just the simplest example that came to my mind
Because:
1. People are fallible and mistakes make their way through.
2. Any sufficiently complex system (and I do mean any, digital or physical) will have weird and unpredictable behaviours when it’s individual parts interact. Most of the time this type of bug is impossible to forsee.
First, because people make mistakes in the code they write, It’s very difficult to account for all possible inputs in any but the simplest of programs. Sometimes you know a bug exists and how to fix it, but it isn’t worth the time you’d spend fixing it. For example, your spreadsheet program probably doesn’t correctly handle dates from 500 years ago.
Second, because people don’t communicate perfectly with each other, and no single person can understand the whole situation. You can have no bugs in your own program, but still get issues because your code relies on the work of hundreds of other people.
Third, even computers aren’t perfect, it’s entirely possible for your program to crash because a cosmic ray flipped a bit in memory somewhere.
Bugs is a super wide area of problems. Some are there by design, someone did define it as it works not thinking of some other side effect this has. Others are just because the developers did not think something could happen(like a person with a special character in the name)
Because people are not perfect neither are they omniscient. Programmers have limited time and resources to get stuff done.
It’s important to understand what Bug is. It’s unexpected behavior.
In a complex system it’s inevitable that from time to time some parts will interact in some strange nonstandard way.
Another reason can be unexpected input. Some users are idiots and no matter how idiot prove you make your system there will always be better idiot who finds a way to break it.
Programs are made on assumptions. You need to make great many predictions about how your system will be used long in advance and this leads to situations where your assumptions were wrong.
When for whatever reason your assumptions are no longer valid you need to step in and make changes in the system to make it work with new assumptions. But you are rarely if ever allowed to rework this from ground up. You just tear the wrong parts out and duck tape your changed functionality in.
And these assumptions can and do change all the time. So you will end up with duck taped mess holding together by the tireless effort of countless programmers constantly fixing them.
Computers are super fast, but actually pretty dumb.
In order to have them perform a specific task for you, you have to explain them as detailed as possible, and in the correct order, what they have to do.
And if your orders are only little bit too imprecise, the computer will interpret it in the absolute worst way possible, just to mess with you.
Because of money!
If you found a project with some money to be finished in 6 month there is a high probability that your software will target basic goals.
It will be not time to consider unusual situation and you will not write down necessary code lines to handle those situations.
Fortunatelly you can declare “this is version 1.0 tested and approved and delivered in time!”
I am proud!
If anyone will found you with new needs and new money to develop a few steps further – congratulations!
You eventually deliver a most amasing version 2.1 – on time and of course “tested”!
🤣👏
Of course. In version 2.1 you can introduce some mistakes – new bugs…
Depending on your proceses of design, coding and debugging – everything is possible.
All above are simplest examples.
What if your code must interchange with somebody other applications – which have version 7.9 etc. etc.?
Because it’s seriously complicated to work out everything that even a very simple system equence of statements is actually capable of doing. And people are fallible, and will make errors. And there’s ALWAYS a budget of some sort, so there’s limited time to do what you have to, and limited time for you and others to attempt to check that you did. The best you can hope is that you caught all the worst stuff.
**Classic real example: IEFBR14**
The first version of IEFBR14, the “shortest possible program” for the IBM OS/360 operating system – whose job is, effectively, “do nothing, and finish”, one instruction in IBM assembly language – had a bug.
The operating system conventions say that, before a program is called, a return address (where to find the code to run after the program has done) has to be placed in a place in memory called “register 14”. So all the program has to do, when it’s done whatever it’s supposed to do, is a single instruction to pass control to the next piece of code. In IBM assembly language, the instruction is the four characters “BR14”, meaning “branch on Register 14 (hence part of the program name). And when all the program has to do is one instruction, and you know exactly what that instruction is, you’d think it couldn’t go wrong. That’s all that IEFBR14 needed to do, so that’s all it did.
Except.
Another operating system convention says that, before a program returns, it should tell the operating system whether or not it thinks that it finished successfully, by putting a number in another place in memory. Zero if it finished OK, something else if it didn’t. And the programmer forgot that, so IEFBR14 didn’t do it. So, actually, even though its job was to “do nothing”, the program still had housekeeping stuff to do that the operating system needed. So – not actually nothing. And because it didn’t set that number, the code that followed would look in memory to see how IEFBR14 got on, and see whatever happened to be in the memory location at the time – which could be anything. And then it would act on that value. So sometimes it worked, but often it didn’t. So the program had to be updated to put a zero into the right piece of memory.
That wasn’t even the last bug. I can’t remember all the fine detail, but I seem to remember that there were two or three other, similar things at least that needed to be “corrected” before the code was finally deemed bug-free.
(Why you’d want a program that “does nothing” is a different topic. It sounds absurd, but in context, it’s actually very useful.)
The computer does exactly what you’ve told it to. I write in English some of the time, but writing software code is not like writing in English, meaning I’m bad at writing code. A person listening to you will understand what you meant when you’re learning a second language, but the computer does not have the ability to understand that what you’re (accidentally) asking it to do is very silly. Spoken and written languages are complicated, but you don’t need to be exact all the time.
Some “bugs” actually turn out to be very useful features. The standard example in video games is Rocking Jumping. Explosive weapons deal damage to players, the man with the bazooka included. Players who take damage suffer some amount of knockback or force relative to the source of damage. Players learned that they could move in a special way and shoot the wall or ground at a specific distance, gaining an advantage in play against their opponents by trading a rocket and some health for speed and distance and height.
Some bugs are beautiful. When making a lighting engine or landscape, one may forget a negative sign in the code. This may lead to extremely odd effects, which may be beautiful or at least hilarious.
Most bugs are probably not useful or beautiful. Software errors are a significant source of stress/expenses/exposure for governments and companies.
Latest Answers