How does computer code break?

Errors in logic, programming errors with the language used; type of programming involved eg. application prgm, operating system executable, etc…. operating system upgrades… can be any number of items… system documentation is alway helpful when fixing programming problems.. Albeit,a general answer, I hope it helps…

Sort of… more specifically I mean how does it go from working to not working? Like I can see how a mechanical part would break from stress or wear, but I can’t see how instructions would break from repeated use.

Upgrades makes sense, since that causes the environment to change.

@kevbo And that’s about it. In a static environment programs that work work, and programs that don’t, don’t. The only other cause i can think of is if the executable gets corrupted. A 0 where there should be a 1 can cause a fair amount of damage down the line.

All sorts of things can break computer code—just one wrong letter or missing space or even cap when it should be lower case. One of the most famous examples and the reason computer bugs are called ‘computer bugs was discovered by Grace Hopper in an early computer relay in the 1946s.
Or have you ever seen the movie Brazil?

Some code will work fine for a while, but then over-time capacities will be exceeded and then things will get screwed up (buffer-overrun).

Say you have a database that can hold 4,294,967,295 entries (this is the highest integer that 32-bits can hold). When you’re building your database you either don’t ever think about the max size, or think that 4mil+ entries will be more-than-enough. But then some circumstance may change (say your company gets bought out by a larger company and they use your database for more than it was intended to handle). Now when you try to add that 4,294,967,296th record, you overload that storage and create data corruption (possibly overwriting the 0th entry with some data from the “4,294,967,296th”.

Other things that can happen involve API’s, or the underlying data changing behind the scenes. So let’s say I built an app that looks at the HTML of Fluther, looks for external links, and then creates a visual collage from the content of all of the external links on Fluther for the day and use it as a screensaver. Now suppose the developers of Fluther decide to change up how they handle links (possibly by using some clever javascript instead of standard links which somehow revolutionizes the site in some way). Now when your app goes to scan Fluther’s site for links to build it’s collage, it can’t see anything because it’s looking for something that is different from what it was coded to look for. The app will continue to do what it was programmed to do, but it will look “broken” since it’s not displaying anything.

These are just a few examples of the kinds of things that can happen.

Unanticpated conditions occur that the program isn’t designed to deal with. It never was, it never could, but it never encountered those conditions before, so it didn’t break.

It mostly used as a metaphor for so-called runtime errors.

After requirements, design, and build followed unit, system, and user acceptance testing and then assuming all of the runtime kinks, syntax errors, bad configuration parameters, etc. have been sussed out of a program, it is finally ready to run in a production environment.

And it’s at that point, that things will eventually go awry. You see, the production environment is the real world. Your program was built to accommodate specific use-cases, but you (and your customer) can only guess so far ahead into the future. New and unexpected conditions for your code to deal with are already on the way.

Perhaps a data input is formatted incorrectly, or has special characters that break your parser, or there’s simply too much of it. Maybe your program becomes more popular than expected and its use exceeds the original design constraints, meaning there’s a risk of exceeding available disk space, RAM, quotas, whatever. Users always tease out new bugs, as they tend to explore and use your program in novel ways that you didn’t anticipate.

Point is, a bit of code doesn’t “wear out” or “break down”. It executes the same every time. But the surrounding environment that supports the program, feeds it, accommodates the results, and all that is always growing, in flux, and will likely evolve beyond what your program was originally coded to handle.

@kevbo …how does it go from working to not working? Like I can see how a mechanical part would break from stress or wear, but I can’t see how instructions would break from repeated use…Upgrades makes sense, since that causes the environment to change.

“Code” in the most concrete sense, meaning a specific string of symbols that you created for a specific context (here, the BASIC computer language), consisting of a sequence of keystrokes rendered as text, doesn’t really change so long as the symbols are faithfully copied and read each time. .

Obviously code doesn’t wear out with repeated use—the virtue of going digital. This might be disrupted, however, by spontaneous flipping of a single bit, which can happen in old floppy disks with weakly magnetized regions, sometimes in hard drives, and occasionally even in RAM by a stray cosmic ray. One flipped bit can be enough to crash any program—like a lethal mutation in genetics.

Let’s say the code executed successfully in years past and hasn’t changed. Why might the same code not execute successfully now? Since your Commodore days, the environment has changed as you already anticipated above. If your BASIC code accesses an input/output device, for example, the BASIC interpreter or compiler (probably the former) might be issuing machine code that’s not valid in this computer or its operating system. That will generate a run-time error, as suggested by @mattbrowne.

Is that what’s happening? In what sense is your code “not working?”