Why errors happen in software development

Understanding why the IT industry is bug-prone

You may wonder why humans can undertake large and complex construction projects successfully, and yet IT companies struggle to deliver software projects without bugs.

To put it in perspective, Facebook—with over 5,000 employees to keep its portal running—released this message to its users: “Even with a strong team, no company can ensure 100% prevention of bugs, and in rare cases we don’t discover a problem until it has already affected a person’s account” (2013).

In an attempt to explain why, we discuss various reasons errors happen in software development. This is not meant to tolerate shoddy software development practices—rather, we're saying that even with an excellent process in place, software development remains a highly challenging field.

Software complexity

Any software that is developed to function for specific purposes is extremely complex and no single person can conveniently understand it. Complexity of software also means that it’s impossible to test its every path. To address this, IT companies implement processes that are likely to increase the chance of minimizing errors. Use of different techniques such as setting up coding standards and use of testing methodologies are expected to improve the quality of the software.

Programming error: each line of code can be a possible cause of bugs

Each line of code can have thousands of possible inputs, outputs, states, or dependencies to deal with. We can say that it is possible to document every test case for every line of code, but we still cannot be sure that there is no unknown factor that can cause an error. A line of code is a part of a whole system, and the whole system needs to be tested to make sure that all parts of the application work correctly.

Ultimately, software is created by human beings, and humans are fundamentally prone to make errors. As human beings develop software, it will be irrational to expect bug-free software and without any defect.

Most users don’t know what they want until they see it

Even with good input from the users, no one can take away the undeniable fact that only users can think and can know what they really want. The truth is, it is not until they start seeing something and using the software, that users begin to understand what they need.

Clients know what they want in terms of achieving business goals when they decide to let an IT development supplier provide a software for them, but often they don’t have an idea on how it should look in terms of software solution. This is true especially if the software being developed for a new idea or process that they have not used before. Related to this is the next reason.

Changing requirements

Studies have shown that an average software development project experiences about 25% change in requirements from the “requirements completion” stage to its first release. This is a common “scope creeping” problem that hampers nearly all projects. Commonly, users or system owners start to creep in new requirements when the first designs have been done. The design serve as visual basis for them to think more deeply on what they really want—and, thus, create changes.

Changing any software requirement, even a small change, can have adverse effects. High level of interdependencies between the modules, makes the system error-prone. Here are some examples:

  • The initial instruction of the client to its IT supplier is to develop a system where users must first register and log in. The system cannot be used by anonymous and unregistered users. One of the modules, DisplayProducts, is dependent in this log in process. DisplayProducts is a procedure that is used to display a set of products, based on the logged in user. After sometime, the client decided to change the initial requirement and asked its IT supplier to modify the system to allow anonymous users to use the website. Adapting to this requirement change, DisplayProducts procedure may fail because it has no basis on what products should be displayed, since users can now use the website without logging in.
  • Originally, the client wanted Danish as the only language to be seen in the entire website. In the middle of development, the client requested its IT supplier to add English as an option. This change has major impact on user interface. As a result, some text labels may no longer fit in some parts of the web page, if the content in the new language takes more space than what has been anticipated and planned.
  • The client wanted its IT supplier to develop an app that tracks distance of a vehicle. During the requirement gathering, it has been agreed that the unit of distance to be used is meters. ShowDistance procedure was developed to display the distance in meters. The distance output by this procedure is used in creating a report, showing the distance with the correct unit of ‘m’. At some point, the client wanted the app to be modified and change the unit of distance from meters to feet. If ShowDistance procedure was changed to show feet as the new unit of measure, and the report was not updated to show the corresponding unit of measure, the report will be incorrectly showing imperial values with metric labels.
  • A module that calculates employee salary and produces a report has been working in the live server. The client gave additional information that should also be included in the salary computation. When this change was implemented, the module has been modified and tested, and it worked well in the development environment. However, when the system was deployed live, random crashing occurred. This was due to a server timeout caused by the additional processing required to handle the added information, and the amount of data to process. The development environment did not have enough data to trigger the timeout.

All software are affected by external factors

Software is a mindware that should adapt to external constraints. Conflicts brought about by external factors affect software quality. Issues like data formats unsupported by many operating systems, sheer number of different hardware and software configurations, different specifications of hardware and software components from third-party providers, and the like are not controlled by the company developing the main software. Handling and understanding all these external factors is complex, thus making the software prone to errors. The time and cost of development may increase due to adjustment processes to solve concerns and errors brought by external factors, such as:

  • Server and hosting
  • Compatibility with multiple browsers
  • Integration with hardware
  • Integration with third-party providers
  • Integration with existing in-house systems
  • Legacy data formats
  • Scalability
  • Government regulations

There are no hard-and-fast rules to eradicate software bugs, BUT this does not mean that IT companies should be complacent. At the end of the day, it’s the quality of their work—and their business—that’s at stake here. This is why software development firms observe processes, and put in place quality assurance or testing units. They also invest in tools and talents to catch errors, and ultimately improve the quality of the software they produce.

Get a call from Peter and have a conversation about your requirements

Contact us

Peter Skouhus

Please write a short message on the contact form describing your requirements, the challenges you're facing, and other relevant information so that I can prepare before I call. I usually call within 24 hours.

Peter Skouhus

Get a call from Peter and have a conversation about your requirements