Where gods are born

Where gods are born

Unfortunately, bugs are an integral part of the software development process. But I noticed that some teams allow much less bugs than others.

Why does this happen? – I asked.

The first thing that comes to mind is the experience of the developers within the teams. And it would seem intuitively obvious that experienced (senior) developers allow fewer bugs than beginners (junior). But I know many cases where development teams could not stabilize their applications for many months. And such teams consisted only of experienced senior and middle level developers.

Another thought that comes to mind is testing. After all, a test is a tool for checking that the program works as expected.

Indeed, manual and/or automated testing by the developer allows to eliminate bugs at an early stage, and such fixes are the cheapest in terms of labor costs and other negative consequences of the bug. And, typically, successful teams conduct testing at all stages of development. But testing in its nature is the process of finding already created bugs, and it does not prevent the creation of new ones. And so I asked another question:

Is it possible to develop in such a way as not to create bugs?

And before I answer the question, I want to talk about where bugs are born.

Where bugs are born

The development of the program in some ways resembles the construction of a brick house, where developers add new features brick by brick and build the program in this way. And each new brick, read block of code, along with new features also adds new bugs to the program.

The first place where bugs are born

In other words, adding new code to a program creates new bugs in it, most of which appear in the added code. But there are other places where bugs can occur when adding new code:

Birthplaces of bugs when adding new code

As I mentioned, new code is where bugs are most likely to appear, so new code is very often the main object of testing. But this does not mean that bugs appear only there, because, as a rule, new code is built into the codebase and begins to interact with it.

Therefore, the intersection of old and new code is also at risk and bugs can often appear there. The probability of this is lower than in the new code, but it is quite high. And the purpose of regression testing is to check that the old features of the application still work after adding new changes.

But sometimes the program can be so complex and confusing in its design that bugs can appear in those places that have little connection with the place of adding new code and do not directly interact with it. The probability of the appearance of such bugs is quite small, especially for young programs. But if such bugs appear, then, as a rule, the steps to reproduce such bugs are non-trivial and require the fulfillment of many conditions, so finding such bugs is very difficult.

And so, summing up, I highlight three places in the program where bugs can be born:

  1. Inside the new code

  2. At the junction of the old code with the new

  3. Deep somewhere in the old code (consequences of the call from the new code)


I compared the development of the program to the process of building a house. In my opinion, they are really similar, but it is important to understand that in essence these are still different processes.

For example, it is virtually impossible to insert an additional brick into the middle of a finished masonry wall, but in program development, a similar action, inserting a new line of code between existing lines in the program, can be performed very easily. Moreover, programmers perform a similar action regularly, solving the tasks before them. And I decided to depict such an operation in the form of such a pie chart:

Adding new code to existing code

Also, this chart shows the three locations where bugs spawn and their probability of spawning.

And as soon as new code is added to the existing code base, it generates seismic activity similar to an earthquake. Moreover, the codebase begins to shake up a lot if new code is added in many places during the revision. And such “improvements” can completely break the operation of the program.


And it’s sad, because Many developers are forced to change many files, methods and classes in order to make a single revision. And such activity generates bugs, lots of bugs.

And it all looks like the developers are guilty of adding bugs… but is that really the case?

The reasons for the birth of bugs

Undoubtedly, the actions of developers create bugs, because according to their job duties, they are forced to add new code. Therefore, this is partly their area of ​​responsibility, but not completely.

To understand the areas of responsibility, I divided the bugs into two groups:

Technical bugs

Technical bugs are errors like Null pointer exception, Out of Memory, performance issues, etc.

Such bugs arise due to the fact that the developer failed to foresee them, or made mistakes of a technical nature. Therefore, the responsibility for such types of errors lies entirely on the shoulders of the developers. And such bugs can be a problem, because they can block the testing process or even the delivery of the program to the production environment.

I single out the following reasons for the occurrence of technical bugs:

  • Low qualification of the developer

  • Tight deadlines and an emergency mode of work, when the developer is overloaded with tasks and tries to complete each task as quickly as possible

  • Low development culture on the project
    (developers do not follow best practices accepted in the industry, do not use advanced development tools)

  • Lack of developer testing
    (manual and/or automation, e.g. unit, integration tests)

Bugs in business logic

Any program has a purpose to exist, a reason for which it was created. And this reason is usually called business value.

Therefore, the program does some work, a set of actions that brings business value to the customer. And such actions are instructions that developers code into the body of the program. Therefore, developers have to add/change code when the customer’s business needs change.

And new code generates new bugs.

But bugs in the business logic appear even before the developer has written at least one line of code for the new feature. At first glance, it looks counter-intuitive and illogical, because in the end all bugs are fixed in the code, including those related to business logic. This is partly true, bugs are fixed in the code if a bug in the business logic was found after the code was written. And business logic code is always the result of people’s discussions. Therefore, if there were failures in the communication of people in the project team, which gave rise to a bug in the requirements, this will inevitably affect the code, i.e. the bug will be moved to the codebase.

I single out the following causes of business logic bugs:

  • bugs in the communication of people on the project
    (communication between members of the project team, communication between the team and the customer, etc.)

  • the result of a technical bug
    (for example, no NPE error message was received and no other business process was started)


So, back to the question: is it possible to develop in such a way as not to create bugs at all?

In my opinion, this is a philosophical question similar to: is it possible to live and not make mistakes in life?

All people make mistakes, and so do development teams, because they are made up of people, and all people make mistakes.

Fortunately, over the years of industry development, many practices have been accumulated that minimize the possibility of making a mistake. And I highly recommend following these practices, as well as keeping in mind the reasons that lead to the appearance of new bugs.

Related posts