Understanding common software development errors

A programmer’s primary task is to automate the business processes of a given enterprise so that it ends up with a profit for the entity. Simple, right?

It is worth considering the amount of time spent fixing errors in code during daily work. Business owners invest in new functionality or modules, thus spending a significant amount of time correcting the same issues repeatedly, which may not align with the intended tasks or schedule.

Each programmer will probably answer that he would build new systems, modules, and functionalities rather than maintain the old system (which is not quite sure how it works and why).

Following this line of thought, the question we should answer is why bugs are introduced into software that is working on the production? What measures can we take to minimize such situations?

Ignorance of business and functional requirements

It’s fair to say that working on a project at a consulting company or a SaaS application should differ significantly. In addition to differences in working style. Identifying business requirements from conversations with the ordering party, end customers, or application owners is very similar in both cases.

It’s generally known that catching errors in assumptions at the requirements-gathering stage allows for the fastest and cheapest corrections. Hence the importance of properly taking the time to talk to customers/businesses to identify as many assumptions as possible.

A common mistake is starting development work without gathering requirements or before completing this stage. Another mistake is to rush through development, resulting in an ill-conceived code structure. Those causes could impact development velocity in the future. In other words, single feature development time for the same application would be longer and longer. Also, the number of errors introduced could increase because of it.

Misunderstanding of business and functional requirements

To avoid the above problem, work as closely as possible with the business to develop a common language and build a mutual understanding of what the application is supposed to do.

It is also good practice to indicate what the application will not do. That approach will help potential customers fully understand how the application would work.

At the stage of gathering and specifying requirements, the development team should cooperate with the business. The more mediators in communication, the worse (unfortunately).

Ignoring non-functional requirements

Premature optimization is a well-established antipattern. We use that term as an excuse for not preparing the technical requirements. Of course, emphasis on these requirements depends on the scale of the project.

For example, we could cause a negative evaluation of the project by not defining adequate response time for a module critical to the customer.

Insufficient shared knowledge of application modules

Nowadays, separate teams are working on a single application or system. In such a situation, teams must focus on sharing knowledge about every detail related to the developed app.

The matter worsens when working on a legacy project. Working in multiple teams that do not have the same knowledge about the product and the wrong dependencies between modules can only lead to one thing.

Misunderstanding of technology

It is common in legacy projects to encounter the use of a particular tool that contradicts the assumptions described in the documentation.

Introducing a new tool into our project connected with inadequate knowledge about that tool could lead to creating mistaken assumptions based on a couple of sentences from tool docs.

Unfortunately, both cases could end badly for our project.

YDD - Yolo-Driven Development

YDD is the opposite of the approach where we test changes before deploying them into production. “Let’s release to production, and then we’ll see”. Unconsidered changes can cause a lot of damage (not only to the code): - customers may quite often encounter an inadequately working application - changes made on the spur of the moment increase the likelihood of increasing links between modules of the application - such an approach to development is also very irresponsible (and so, at the end of the day, it is WE who will maintain the code)

Working without a plan

When there are hundreds of tasks in the backlog, and we don’t quite know which task is the most important from a business or technical perspective. The manufacturing team may have trouble planning their work. Not to mention identifying major changes that can solve several problems at once.

Work without metrics

Working with legacy code without a proper approach to testing changes. Combined with rushing changes into production. Without proper discussion of how a solution should work. Does this tell you anything? I hope that as few people as possible have encountered this approach to software development.

When the manufacturing team doesn’t have the time or doesn’t want to spend time on requirements identification and testing. There is nothing to dream about metrics that de facto save each developer’s time.

Properly built metrics allow for faster detection of bugs introduced into the software. In addition, we should create metrics that would describe our application (number of requests, latencies, etc.) and the business that we have (number of customers, number of errors reports, number of feature X usages).

Lack of sense of responsibility

In my opinion, the worst thing that can happen to a team is the approach we somehow instead of quality.

Making changes without thinking about architecture and infrastructure

When modules of the application are not well encapsulated then any changes in the code may cause a lot of problems. Performance problems or introduce a bug in a module we didn’t expect.

I can see from my observation that people start thinking about such things when their application is “burning”.

Human error

Of course, everybody could make some mistakes. But at least introduce the techniques described above: collection of requirements and introduction of tests or metrics. It will significantly reduce the effects of human error.

Summary

Hope that list will help you spot such things in your project. That would be a good start to improving it!