If you have ever had anything to do with programming or coding, there is a high probability that at some point your program has inexplicably crashed. Your screen flashes red with an error, the world ends, you give up and run away.
Just kidding, but you may feel like doing that.
Your code may have crashed because you have not installed the correct packages, or you have missed out on something, but for the most part, software will not work because it contains errors, often referred to as bugs.
This is part one of a two-part blog on bugs and features.
In this post, we will be working through what exactly bugs and features are. In the second part, we will look at the etiquette of bug fixes vs new features in software development.
Let’s dive in.
What Are Bugs
The term “bug” is used to describe problems with, or defects in, a product. The term has been used colloquially in engineering since the early 1870s, well before computers and software were a commonplace.
Thomas Edison wrote the following in a letter to a colleague in 1878:
“It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that ‘Bugs’—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.”
The above-mentioned quote from Edison refers to a bug in the mechanical engineering sense. In software development, a bug is more commonly an error, flaw, or fault in a program or system which results in an incorrect or unexpected response, or results in unforeseen behavior from the product.
In the 1970s, Gary Kildall referred to these errors as “blunders” due to the fact that they typically arise as a result of human error, or a mistake made in the code.
There continues to be debate around what these errors should be called, as the word “bug” can to a degree divorce the error from the idea that a human was the cause.
These errors can take many different forms, and it is often a long and painstaking process to find and eliminate errors. This process of finding and fixing bugs is commonly referred to as “debugging“.
Oftentimes a developer will make use of pre-existing tools to pinpoint bugs, or to allow the developer to step through the code and see where a fault may be.
Possibly the most famous bug to date is the Year 2000 problem, also known as the Y2K bug.
The problem or potential bug that was faced here was the fear that there would be a worldwide economic collapse at the start of the new century as a result of computers thinking it was 1900 and not being able to roll over to 2000. In the end, nothing came of it and fortunately there was no economic collapse.
What Are Software Features?
A feature is a discrete piece of functionality that is requested and desired by stakeholders, or a change request that must be fulfilled.
In the case of a software product, there are two groups of stakeholders, the internal and external. If you wish to read up more on the stakeholders, try reading Oliver Dolans’ article on “Who are your stakeholders in Agile projects?“.
In summary, the stakeholders are people or organizations who have a vested interested in a product.
In the internal stakeholders’ case that may be the product owner, product champions, various departments within a company, or even the software development team. And externally it could be the customers, suppliers or industry partners to name just a few.
How Do Bugs And Features Relate To Each Other?
- Bugs degrade the value of the product whereas features can enhance the value of the product.
- Bugs occur when the product does not meet the product specifications, or end-users expectations, whereas a feature is an end-user expectation from the product (something that the end user requires).
- Bugs are a mismatch or failure based on the requirements, and a feature is an application functionality developed for customers. It can be a new requirement or changes in existing features.
- Bugs will primarily be discovered and corrected by a testing team, and features will primarily be requested by the business, but sometimes they are also requested by development and testing teams. The final features added will normally be at the behest of the client, customer, or business.
Bugs as Features
Mixed into all this is the concept that there are times when a really nasty bug can actually become a good feature that can improve the user experience.
This is often where a portion of code will either be refactored to correct the error by adding a feature, or the section of code will be removed and replaced with a feature.
Features as Bugs
There is also the case where a feature may be interpreted as a bug. This happens when a feature is not correctly integrated into the product, either in the flow of the frontend, or the feature is not commonly used.
As such when the user stumbles upon it, it may be interpreted as a bug or may interrupt the users’ interaction with the app that it sufficiently irritates them.
To put this into context lets look at a pretty common example. Let’s suppose a development team has been working on a new web app. The following may occur whilst the product is being created:
Change in existing feature leads to a bug
Suppose that an application has been created such that when the user completes the login, a series of graphs will display and slide across the screen.
It was then decided by the marketing team, that one of the graphs that slides across the screen needs to be plotted in live time. However, the following bug occurs:
- The time allocated for the graph to plot is insufficient. The graph does not finish plotting in time, but continues to plot even when the new graph is displayed, resulting in half of the previous graph being plotted onto the following graph.
- The follow on of the previous graph onto the next one distorts the graphs and leads to none of the graphs rendering or plotting correctly.
In this case the feature that was added has resulted in a bug. The most effective solution would probably be to just fix the existing bug, instead of implementing a new feature, though this will be explored in the next blog.
A bug results in a new feature
Let’s look at the Gmail unsend feature in this case. This was not a bug in the sense that there was an error in what it was doing, but rather there was a lag or delay that existed because Gmail typically took around 5 seconds to process and send an email.
This was a significant amount of time when it comes to a process performed by a product. As a result, the development team implemented an unsend button that would interrupt the process if you decided within those 5 seconds that you didn’t actually want to send that email.
Admittedly, this worked out really well, and has saved a lot of people a little bit of embarrassment in the long run.
Conclusion
In most cases, a developer will not turn a bug into a new feature. It’s often considered bad etiquette and can potentially lead to further issues. The developer will typically find a different solution or a way to eliminate the bug entirely.
If this is not possible, then one would approach the client and explain the situation to them, before trying to resolve the problem.
