"Every software has flaws"

A software has errors and sometimes does not work as intended. That is quite normal, so let us have a glance at the topic at hand.

A software error, often referred to as a bug, is generally a misbehavior of a computer program. This occurs if the programmer has not or incorrectly implemented a line of code, leading to a different outcome than actually intended. Furthermore, incompleteness, inaccuracy or ambiguities in the specification of the program can also lead to "errors". In order to detect and eliminate program errors as quick and economically feasible as possible, software is usually tested during the software development processes, i.e. before the actual commercial use of this software (or its new features). Errors occur commonly during this phase and finding and fixing them is a priority.

Software rarely occurs without errors, but usually there are safety measures in the background to ensure it still keeps going (default values it can refer to, for instance). Programs with an error density of less than 0.5 errors per 1000 lines of code are considered stable programs. As special tools to search for the causes of errors in programs, debuggers are helpful, with which a program can be executed and controlled step by step. In the case of particularly critical software (e.g. aircraft control), formal verification is sometimes carried out.

Sometimes though, unexpected errors during live-operation may present themselves and slipped past the testing phase. So-called bug trackers (e.g. JIRA) are used for recording and documenting these. They also serve as a platform for suggestions, improvements or requests from a Customer. The process of fixing a program error is called "bugfixing", the result is called a "bugfix". An immediate response to it might be referred to as a "hotfix", if the issue has been resolved and the need arises to update the software immediately.

Our project management, in the technical sense, is based on the so-called "agile software development". We strive to manage the project efficiently and pragmatically with little bureaucratic effort, few rules and usually an iterative procedure, to implement new features, updates on existing ones and even fix bugs seamlessly over night. Expectations towards a software are often high and rarely can be met immediately, especially when a part of the software is undergoing immediate changes.

Disappointment may arise when expectations do not correspond to reality, like a new bug which seems to practically spawn and occur over night. Users may get disappointed and eventually discouraged by continuously encountering software errors. This is relatable, but an important part of the process to improve upon a software and broaden its scope. The only reliable way to ensure flawless software quality is to write less code, thus less functionality, resulting in a software being able to perform fewer operations. However, such an approach is very rarely compatible with commercial success and corresponds negatively with the motivation of developers to improve upon their program. While users might be enthusiastic about the "Stop the train, we must repair the tracks"-concept in software development, this approach rarely sees commercial success. Another approach might be "can't they just hire more developers and testers to fix all the bugs?".

Modern software development does not work like this and is economically not feasible. Larger teams might even prolong the process of bugfixing. New developers need time to get into the source of the software for them not creating even more errors or bugs. These are an inevitable by-product writing lines of code of any program, even crucial operating systems you use any day are plagued by them - but the software makes up for it in enabling you to use various Apps or Tools integrated within, suited to your needs. These are also likely to have their share of bugs.

Once we accept this simple fact that a "software has errors", we can make progress to understand why fixing each of them immediately is not possible. The lack of errors and fixing the existing ones is one of many parameters in a software's success, but by far not the most important (with some exceptions for life-critical software). A software can be completely free of bugs and yet remain completely unattractive to the commercial market - because it lacks features the customers want to see. On the contrary, a software might be faulty, but still remains very valuable due to its versatility. The value of a software depends much more on its features and the problem it solves, providing a solution for various tasks, than on the quality of how it does and handles this in the background. You could have two programs solving the same problem, and it is reasonable to think that the better software is simply the one with less errors.

Despite thinking so, even this simple statement is often refuted by the potential economical growth of one's software, allowing it to be even further developed and reach new heights quicker than its competitors. Very often, tight software is made for very specific goals in mind, but are hard or maybe even impossible to be improved upon. Factors such as api-integration, existing brands and its associated software or even the fun-factor often overshadow the lack of quality. Thus, it is not surprising that not every bug results in a "drop everything, we have to fix it right now!"-attitude. The value of each error can be evaluated by the number of users affected and how grave of an impact it has on the software at hand.

Several examples:

• Is the bug actually hindering your Daily Business or you might even loose data? Other users could potentially also be impacted by this?
  → Solving it becomes an immediate priority.
• Is an error confusing or not plausible/it's not clear as to why this error occurs, but it does happen frequently?
  → Solving this is a higher priority than usual and if possible, will be fixed very soon.
• A few users need to spend another 30 seconds working around a bug which occurs every week once?
  → Solving this immediately is unlikely, but will be in the foreseeable future once possible or another bug is currently being fixed associated with this one.
  
  

Software organizations that remain in business prioritize their needs. You don't drop everything to deal with a minor hiccup or mistake. The scale of this error effects the extent of the consequences of such prioritization. Large software packages often have hundreds, if not thousands, of open "bugs" of varying severeness. 

If you discover an error, respect it for what it is and be sure to reach out the software's associated support-team or developers - especially if it seems to hinder your daily business going round.

We, Nexxchange, strive to provide you with a toolkit to solve many of your issues at hand. We will make sure to evaluate your feedback properly and are always happy about your continued support to create an even better software - Together.