Editing Software bug (section)

== Debugging ==
{{Main|Debugging}}

''Debugging'' can be a significant part of the [[software development lifecycle]]. [[Maurice Wilkes]], an early computing pioneer, described his realization in the late 1940s that
“a good part of the remainder of my life was going to be spent in finding errors in my own programs”.<ref>{{cite web
|title=Maurice Wilkes Quotes
|url=https://quotepark.com/quotes/1810905-maurice-wilkes-by-june-1949-people-had-begun-to-realize-that-it-w
|publisher=QuoteFancy
|access-date=April 28, 2024}}</ref>

A program known as a [[debugger]] can help a programmer find faulty code by examining the inner workings of a program such as executing code line-by-line and viewing variable values. 

As an alternative to using a debugger, code may be instrumented with logic to output debug information to trace program execution and view values. Output is typically to [[System console|console]], [[Window (computing)|window]], [[log file]] or a [[computer hardware|hardware]] output (i.e. [[LED]]).

Some contend that locating a bug is something of an art. 

It is not uncommon for a bug in one section of a program to cause failures in a different section,{{citation needed|date=November 2012}} thus making it difficult to track, in an apparently unrelated part of the system. For example, an error in a graphics [[Rendering (computer graphics)|rendering]] routine causing a file [[I/O]] routine to fail.

Sometimes, the most difficult part of debugging is finding the cause of the bug. Once found, correcting the problem is sometimes easy if not trivial. 

Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmers. Often, such a ''[[logic error]]'' requires a section of the program to be overhauled or rewritten. 

Some contend that as a part of [[code review]], stepping through the code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such.

Typically, the first step in locating a bug is to reproduce it reliably. If unable to reproduce the issue, a programmer cannot find the cause of the bug and therefore cannot fix it.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the [[Therac-25]] radiation machine deaths was a bug (specifically, a [[race condition]]) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called ''[[heisenbug]]s'' (humorously named after the [[Heisenberg uncertainty principle]]).

Since the 1990s, particularly following the [[Ariane 5 Flight 501]] disaster, interest in automated aids to debugging rose, such as [[static code analysis]] by [[abstract interpretation]].<ref>{{Cite web|url=http://christele.faure.pagesperso-orange.fr/polyspace.html|title=PolySpace Technologies history|website=christele.faure.pagesperso-orange.fr|access-date=August 1, 2019}}</ref>

Often, bugs come about during coding, but faulty design documentation may cause a bug. 
In some cases, changes to the code may eliminate the problem even though the code then no longer matches the documentation. 

In an [[embedded system]], the software is often modified to [[workaround|work around]] a hardware bug since it's cheaper than modifying the hardware.