Encountering website bugs can be an extremely frustrating experience, especially when the website in question is your business's website.
Fixing bugs generally follows the same overall process of:
Cost and timings can vary significantly depending on the elusiveness and complexity of the bug in question.
The first step that needs to be taken is to find a way to make the bug happen every time. We need to be sure that we can put the website into the state where it is failing so we can see what is happening at that moment. Depending on whether the bug is consistent or intermittent should set your expectation for how troublesome it will be to resolve.
A bug that is consistent is generally bad for the customer but great for the problem solving process as it can be easily reproduced and therefore investigated.
A bug that is intermittent may not significantly impact customers’ experience, however it will create a setback for the problem solving process. Bugs that are intermittent need a lot more time committed to make them appear in order to be investigated.
Once we are able to reliably reproduce the bug every time without fail this allows us to investigate the bug itself.
The steps a development agency will take to investigate the bug will vary drastically depending on the:
Individual skills of the developers and their expertise are important here to take the right path in the investigation.
The goal of the investigation is to keep narrowing down the location of the problematic behaviour till it can be pinpointed and a full understanding of how it happened and what causes it can be established.
We can often do this by slowly stepping through the process with purpose-built debugging tools, checking the state of the website for anything unexpected at every point. Each time that we find something unexpected we follow that path further, sometimes this leads to dead ends in our investigation, but eventually we will discover the entire chain of events that causes the bug itself.
Having the understanding of what causes the bug is usually most of the job done. Generally knowing why it doesn’t work is enough of a blueprint to tell us what we have to implement to make it work.
Implementing a fix is usually the fastest part of the entire process. This is because generally the root cause of all the side effects tends to be a mistake or oversight either from the original developers or due to a poorly briefed website/feature.
Often the fix can be implemented in a matter of minutes once it is identified. However in some cases the root cause is not necessarily that anything is wrong, but rather it was never implemented in the first place and requires an alternate solution such as additional development.
When a fix is not possible, we may be able to implement a patch instead, which is a very temporary workaround to prevent the original bug causing a dead end. For example, instead of allowing a website to break entirely, we may add a message explaining this feature is currently down and to direct their query elsewhere to keep business moving forward.
Sometimes the outcome of investigating a bug reveals that additional development is required.
Additional development is often required in situations where the original brief did not have the required scope to cover this use case, which is not uncommon and often website projects should always be followed up with an ongoing maintenance service to keep evolving the websites with emerging requirements and a changing landscape.
Additionally development may be priced up as ad-hoc work or a mini project. Alternatively this may be the time to look into a maintenance package as bug investigation and small features are generally covered.
It is often impossible to determine how long a bug will take to resolve, this is because the scope of the work cannot be defined. The more investigation work that is done generally the clearer a picture we can gain of the time left.
With regards to timelines any ballpark is likely to be wildly inaccurate, although if you have worked with the agency or developer for a while they may have a better mental map of how your project works and therefore is likely to come up with a more reasonable timeframe.
The total cost of resolving a bug is also very difficult to establish, this is because often 90% of the work involved is around identifying the bug itself, whereas only 10% is for applying the fix or making recommendations about the additional development.
For this reason agencies and developers often can’t give an estimate, to come up with the estimate of the fix is to implement 90% of the work upfront.
Bug fixes are generally one of the few services that come with an hourly rate instead of a project cost because it is the only way to offer mutual fairness to the agency and client. An hourly rate ensures that all development efforts are paid for, while making sure the client never overpays on an inflated ‘safety’ figure for the agency.