Anatomy of a Bug

Many non-technical stakeholders believe a bug is exclusively the result of programming ‘mistakes.’ However, this is often not the case; there can be many causes for what people colloquially refer to as “bugs.” In this article we’ll go through some common ones, but first, let’s provide a definition of a bug.

What is a bug?

Fundamentally, a bug is a mismatch between how the user expects a product to behave and the way it does behave. (In fact, one of the most common formats for reporting a bug includes a description of the expected behavior and the actual behavior, both of which are required to specify the bug.)

Causes of bugs

Now let’s take a look at common causes for bugs, keeping the above definition in mind.

Programming for safety

Developers think hard about what can go wrong in a product, and how to prevent such situations from arising. In the process, programmers often make certain actions impossible, so as to prevent users from accidentally doing damage to the system. However, for an end user, this can be frustrating, and even result in a bug report.

As an example, imagine a product built to allow collaborative form editing: it has fields created by an admin, and workers fill out the form. Now suppose the admin decides that a field is positioned improperly, and so attempts to delete/recreate the field in the right place. When they go to save the revised form, however, the old field is still there. The company then reports this to their developers as a bug.

Is this a bug though? Let’s consider. When building the product, the developers considered data loss to be a worst case scenario, so they made it impossible to lose data (this is a good thing!). When the admin attempted to delete the old field, this would have resulted in all the previous data that workers inputted to it to be lost – so the system behaved as designed and prevented that loss.

However, obviously, this is preventing the user from doing something they want to do. It should be changed in some way or another. But ultimately, this isn’t a mistake per se – the system was behaving in the way it was designed, and it was designed in a reasonable way. While it was reported as a bug, it amounts to a new feature request.

Unsupported behavior

Similarly, sometimes a user will attempt to do something that the system does not support. As an example, consider a business equipment rental application, wherein a user can submit a request to their project manager to rent some equipment.

A bug is reported to the developers of the application: a user has attempted to submit a rental request repeatedly, but the application reports an error each time. However, upon further investigation, the user was attempting to insert emoji into the comment box – which is not supported by the database.

Is this really a bug? Had the consultant, from the beginning, suggested that supporting emoji be a top priority, the client would have balked – the application is for business purposes, so supporting emoji would be an unnecessary expense. If the client wants to support emojis, then that would reasonably be a feature request.

Overuse of a supported feature

If you’re familiar with the term DOS, then consider this as an accidental DOS attack. Sometimes users will make use of a feature far more than the developer (or business!) expected. For example, suppose a social media application has a feature wherein a user can upload a series of photos and the application’s server will generate a collage from them. As long as only a few people are using this feature at a time, everything works well – however, if the feature suddenly becomes very popular, it might end up overloading the server.

Is this a bug? If so, it’s a wonderful bug to have – it means that your service is popular! However, it obviously needs to be handled, and, again, a new “feature” would need to be requested to support the popularity of the collage making function.

Unexpected combinations of usage

Apps are complicated; they often involve tens or hundreds of thousands of lines of code. Users, too, are complicated. When these two sorts of complications interact, the results are often unexpected. We at LithoByte have often seen startups be shocked by how actual users end up using their app – not seldom is it ways that are completely counter to the way it was designed.

When a system’s features aren’t designed to be used together based on the client’s expectations of end user behavior, strange things can happen; and sometimes those strange things are reported as bugs. The important thing to remember here is that startups have limited resources – so planning for every possible use case is combinatorially, not to mention financially, infeasible. Again, if it comes up, it certainly needs to be resolved, but it is not a mistake, per se.


When a startup founder describes their product, they have a complete vision of it. However, reducing that vision to the imperfect medium of spoken or written language will necessarily result in an incomplete picture. When a developer then takes that incomplete description and attempts to translate it into code, even more of the original vision will be lost. (This is one of the many reasons LithoByte recommends an iterative approach to development – it allows us to work with our clients to, with time, bring the actual application closer to their vision of it.)

Miscommunications are a part of the process and happen in every project. When a product is designed differently than the stakeholders intended, it is an opportunity rather than a failure. By allowing lots of opportunities to identify miscommunications, you end up with a better product overall.

Genuine oversights

Given the above, a relatively small proportion of ‘bugs’ are actually oversights or mistakes. However, every piece of software is imperfectly built – the question is not if a product has bugs, but whether they bother end users enough to cause a company to lose money. In this way, rather than trying to aim for a bug-free application, aim for one that users enjoy using. That doesn’t mean that everything they try to do with it will work – only that users will give you the benefit of the doubt. And when you run across a genuine oversight, which at some point you almost certainly will, it’s important to regard them as an unavoidable part of the process, fix them, and attempt to prevent them from happening again.