Humans, Machines, and Money are all involved.

The very first year of my software developer career was spent as a bug killer. During that year, I could feel that nothing new was being added to the product; everyone seemed to be spending a year, or even more, fixing bugs that had been created over the prior two years of coding. It sounds expensive, right?! The cost of fixing bugs includes not only employees’ wages but also the trust of customers, and sometimes results in being a loser to your competitors. At least that year taught me how things can be done wrong, and I do believe that knowing how to do it WRONG is even more important than knowing how to do it RIGHT. Every mistake is worth learning from, whether it’s yours or not.

1. How are humans involved?

Testers usually blame developers for bugs. Actually, it’s true, but remember that they are the source of other non-bug issues. People make mistakes all the time, unconsciously, and so do developers and testers. Seniors will make fewer bugs than Juniors, not because Seniors are smarter, but because Seniors have already made all of those mistakes in the past. Intelligence only helps to identify and solve problems faster; it does not help to avoid problems or mistakes. The job of testers is to help reveal developers’ mistakes and ensure the product’s quality, so avoid carping and blaming developers for bugs.

1.1. Programming Errors

The easiest-to-fix bugs are Programming Errors. Yes, this is all about developers. Programming Errors include:

• Syntax error : Each programming language has its own coding convention. Newbies in coding usually make those mistakes because they do not yet have a full understanding of predefined conventions. Sometimes they are not aware that the style of coding even exists.
• Semantic error: When the coder becomes familiar with syntaxes, they can literally tell the computer to do things they desire in a specific order of steps. However, sometimes, some steps conflict with others, such as altering a value that is still not available, or steps being executed in the wrong order, which leads to producing an incorrect result. Null pointer exception may be the most famous error that developers and testers have ever encountered during their jobs. It occurs when the computer is asked to read a value that doesn’t exist in its memory. The more experienced the developer, the easier it is for them to avoid these errors.
• Logical error: Even multiple years senior developers still make this mistake. It occurs when a developer has to translate their understanding of a requirement into lines of code. As a human, and depending on the efficiency of the communication method, they may misunderstand the logic and then produce misbehaving code. When a developer has a correct understanding of the requirements but still produces wrong outcomes, it is due to subsequent reasons.

1.2. Communication Errors

The next level of complexity bugs arises from Communication Errors. This time, it involves everyone: product owners, business analysts, developers, testers, managers, and the cats of developers.

There are always communication gaps between any couple of people. If a team lacks cooperation or is weak in cooperation, its number of members does not reduce development time; it increases because the more inefficient communication is, the more problems arise. And again, please don’t misinterpret the difference between communication and talking, chatting, or gossiping. Communication errors here are about the misdistribution of information between people. It is the lack of reporting systems among stakeholders. A lack of information leads to misunderstandings and conflicts, not only in human aspects but also in the product design and development process.

1.2.1. Reporting between Developer and Developer

This is the most common problem in a development team. A typical phenomenon is that a developer usually reinvents something that already exists, not to improve or overcome some limitations, but because they are unaware of its existence. As we know, any invention must go through a lot of mistakes, and reinventing means facing those mistakes again. A mistake is a bug!

Within the scope of developers, the lack of reporting on what has been done, what is being done, and what will be done creates blind spots in decision-making regarding how to write code. Writing new features is time-consuming and much more error-prone. Using existing resources without documentation or guidance is also prone to errors. A well-organized tech meeting is a good practice for disseminating information. A comprehensive technical document and effective distribution methods can also ensure that developers’ knowledge is synchronized and, thus, less error-prone.

1.2.2. Reporting between Business analyst and Developer

Lacking reporting on what is doing well, what is doing poorly, and why this, not that also creates smoke lines in developers’ minds. Everyone has their own past, and that past creates assumptions. Sometimes you find out a developer builds things in his own way, believing it is correct, but it does not fit your current business logic. Don’t assume people understand things your way. To help developers understand the situation, please also let them know what customers do, how customers do that, and why customers do it that way.

1.2.3. Reporting between Product Owner and Business Analyst

This is usually merely verbal communication. This communication step turns an idea into detailed actions that developers will later engage with. An idea is something mutable. The change in an idea creates a change in requirements. If changes in requirements are not clarified carefully, they can cause conflict with old requirements or mismatch with them. In this case, even if developers do exactly as the requirements say, the software can still have bugs. This is known as a business logic bug. To reduce this occurrence, a business analyst should have a method to oversee the impact of business rules, allowing them to report potential problems to the “idea generator” early. This, in turn, enables collaboration with the Product Owner to clarify the final and safe actions needed. The Product Owner should also provide a clear vision and strategy so that everyone has a particular destination in mind, which helps everyone adjust their own actions to fit the strategy. Do you believe that the idea itself can bug?

1.2.4. Reporting between Employee and Manager

Managers are familiar with reporting. They use information reported by other stakeholders to create detailed action plans. For some reason, budget, for example, or mis-estimating required effort, the deadline for an action is sometimes too tight. It creates a time pressure on developers and testers. With limited time, everyone will choose the fastest way. Developers will choose a hard-code solution, testers will miss some test cases, and eventually, bugs will emerge. Hard-code is like curing an illness by covering up symptoms without applying time-consuming proven treatments.

1.2.5. Reporting between Testers

The job of a tester is to manage test cases and go through them regularly. With some coding knowledge, testers can write automation tests that can automatically run after every change in requirements, big or small. This is the most efficient way for testers. In some cases, testers are non-technical, and developers usually take care of this part as well. Without automation tests, testers will have to manually test each case after each change in requirements. Testers should not assume that developers will take care of all the effects of the change on other functions. Sometimes developers are not even aware of that. Fixing bugs can create bugs too. So, if you are tired of manual tests, create automation tests.

1.2.6. Mental Health

The cat of employees – This is a metaphor for employee’s mental health. It does affect to employee’s alertness and is a cause to create mistakes. A broken heart is more likely to destroy the system more than a normal one, right. So, make sure your team is heathy.

2. How are machines involved ?

Beside mistakes obviously made by humans, there are some objective conditions that can cause your software to run undesired behaviors, which customers can report as bugs. In fact, someone can blame developers for their inability to anticipate those conditions; however, please remember that this is also due to testers’ inability to foresee those conditions, and they are not always outlined in the requirements written by BAs or Product Owners either.

Experienced developers can be aware of those situations and can provide early solutions. But everything takes time. Especially, solving those kinds of bugs requires more effort than the ones mentioned above. Testers should be aware of those situations and learn more advanced testing techniques so that they can help to reveal those problems early before they happen to end users.

2.1. Incompatibility

Your customer’s machine can have some limitations to be sufficient to run your software. It can be a low memory computer (RAM, Hard disk) , old (weak) processor or out-update Operating System. Every software will need a minimum available memory and pre-existing components for initializing and further executions. When the computer run out of resources, anything can run improperly. Every software should be shipped with a system requirement note, it can act as a disclaimer term for your team.

2.2. Memory Consumption

With the same problem, each developer can have different solutions, and each solution has a different speed and memory consumption. Memory is a limited resource. Much or less, this depends on the developer’s skill. But with today’s computer power, a few gigabytes of memory is usual, so it makes most developers in most situations not care about memory consumption anymore, until it crashes.
Running out of memory is not only caused by your own software. A computer can run many programs at the same time, so it is not always because of you. It is best if the software can notify users about its memory situation so the user can understand what is going wrong.
In the context of web servers, each request is allocated a maximum amount of memory. This practice is to ensure the server can handle hundreds to thousands of requests per second. The code written by developers may not consume so much memory, but it may exceed this threshold. Many other components behind the scenes, like databases, proxies, and other third-party services, are all vulnerable to this problem. So, to developers, never assume everything will go well; always prepare for failure because bad things do happen.

2.3. Unstable Network

Offline-only software has nothing to worry about regarding this. This is more important for software that uses a client-server model. Most applications nowadays are based on the client-server model. The connection quality between client and server is extremely important, especially for applications that require real-time responses like stock market updates, online gaming, or streaming services. The technology behind these applications already has some tactics to recover or endure under unstable networks or low bandwidth connections, but they are “try their best” only; don’t expect it to be magic. The ability to work under low bandwidth or unstable connections is a key competitive factor for applications like video streaming. Testers should be aware of this and must have serious test scenarios.
To optimize solutions to ensure the software can function under these conditions, developers must have deep knowledge of computing and networking. Fixing these kinds of bugs is extremely hard. Don’t expect the solution to always be available; even current technologies still have some limitations.

2.4. Offline Accidents: Electricity off

Offline Accidents: Electricity outages can occur for various reasons. A sudden shutdown can cause some functions in a program to fail partially. This can lead to problems upon the next startup, such as mismatched data or corrupted data. Some software that handles sensitive data, such as in the banking industry, usually has recovery strategies—both digital and non-digital—to protect the business from damages.

3. How is Money involved?

The budget of a project affects the plan in time pressure and the priority of work. Most of the time, developers will focus first on writing code to fit business logic and set aside potential problems regarding the machine. It makes sense because we should avoid premature optimizing: how certain are we that potential problems will happen? This ignorance due to priority reasons produces something called technical debt, and every debt needs to be paid, sooner or later, with or without interest.

Budget determines the quality of team members. It is obvious that the more experienced employees are, the more benefits they expect. Experience means they are aware of mistakes and have a way to avoid them. When they know how to avoid mistakes, they know how to do it right.

Budget affects employee’s motivation. Motivation makes them do their best to make the best software they can. Sometime your software does not make money enough to ensure that kind of employee’s motivation or minimum member quality, remember my question: “Do you believe that the idea itself can bug“? If your software does not make enough money YET, why not share your vision with everyone and let them be one of it. Excellent people who willing work for joy and opportunity still exists, trust me !!.

Conclusion

Above are some insights from my debugging era. I hope they can help illuminate some mysteries from the developer world and assist teams in taking more appropriate actions to deal with bugs. Feel free to comment on anything you are interested in or do not agree with. Thanks for your time.

Build – Secure – Evolve with the-tech-lead.com

---