Debunking the Web Development ‘5 Minute Fix’ Myth
The idea that it only takes 5 minutes to add or alter a line of code is a myth perpetuated by television and movies. I’m sure you’ve seen those scenes where the protagonists find themselves in an end-of-the-world scenario; then thanks to a stereotypically tech-savvy character, they manage to swiftly hack into a secure government network. A quickly typed line of code and the world is saved...
As a developer, this makes me cringe!
Thankfully, I’ve never found myself in the position of having to save the world in the next 5 minutes. This is not really a world that developers work within. However, scenes like this often influence the expectations of those who aren’t developers.
To better understand the development process, let’s consider the case where a single line of code needs changing (a rarity in the real world).
THE HOLLYWOOD FANTASY
As the movies have implied, the developer has the code in front of them, or is just a click away. They instantly know how to fix the problem and edit the line of code causing the bug. They hit save and the website is updated and everything is good.
Just like in the movies, the developer is infallible and therefore hasn’t had to test their code. It just works.
BACK TO REALITY
SETTING UP
It’s highly unlikely that the developer has the code so readily to hand. For example, at a busy agency, developers often work across multiple projects. So, one of the first things that they need to do is install a copy of the site on their own machine before they can begin fixing the bug.
If the developer has worked on the project before, they probably have this bit sorted, but still need to get it opened up ready to work with.
RECREATING THE BUG
Next, the developer would make sure that they can recreate the bug in their local test environment using the code that they have installed on their computer. This is an important step as it ensures that the developer can have confidence that the fix, that they later apply, actually works.
Good instructions from the client and project manager are a massive help here.
ISOLATING THE BUG
With the bug recreated, the developer needs to find the file and line where a fix needs to be applied. The developer will look at error logs, run tests and utilise other debugging tools at their disposal.
Here, we are just considering a case of a single line of code needing to be changed. It is more usually the case that multiple files and lines of code need to be modified. Locating where changes need to be made can sometimes be simple, but often developers will need to spend some time determining where the bug is actually originating.
IMPLEMENTING A FIX
Once the source of the bug has been identified the developer can go about writing a fix.
Sometimes a fix is obvious. Other times they will need a little more thought. Either way, the developer needs to take careful consideration of any knock-on effects caused by the change they are implementing.
The developer will test their fix on their local installation of the website. This often requires additional testing of other parts of the site in case the fix has affected something elsewhere.
Depending on the cause of the bug, or the fix implemented, the developer may also need to document the solution. This can help ensure that the bug does not reoccur at a later date. Similarly unit tests may be written; unit tests are small bits of code that can be automatically run to ensure parts of the main codebase are working as expected.
PEER REVIEW
At Evoluted, once the developer is happy with their fix they commit it to a temporary branch of the code, then submit it for peer review. For us, this is an important part of the process as it utilises the experience of the wider development team. It provides an opportunity for other developers to test the fix and ensure there are no other issues.
We may skip peer review if it’s something as simple as a typo, but code changes generally want reviewing because even the best of us make mistakes.
When submitting a fix for peer review, the developer that worked on the fix provides details of what is being changed (as well as why) and instructions on how to test.
Other developers will test the fix and check the code looks fine. If they have any questions, suggestions or issues they raise these with the original developer.
FURTHER TESTING
After the fix has gone through peer review, the fix is deployed to an internal staging server.
The developer will provide test instructions (and check they work on the staging server) then hand this over to the project manager to review. This is a final internal test to ensure that the fix meets the requirements.
If everything is good on the staging server, the developer will be asked to deploy the fix to what we call our UAT server. This is where the client will be invited to test the changes.
GO LIVE
Once the client is happy with everything, the developer can deploy the fix to the live website.
Again, the developer will check that everything is working correctly. For e-commerce websites we usually also test the checkout process, even if the fix is unrelated to this, to ensure nothing has inadvertently broken in the process.
WAS THAT 5 MINUTES?
The reality is very different from the Hollywood fantasy.
At Evoluted, the expertise and knowledge of the team are always utilised to keep changes to a minimum. However, there is more to fixing a bug than just writing a line of code. A lot of the time is spent testing. Over the years that I have worked as a developer, I have learnt that most of my time is spent testing, followed by reading existing code. Actually writing code is a small part of a developer’s role.
There are many stages to fixing a bug as detailed in our example. However, this didn’t take into account things like design time, planning, discussing and estimating the task; these all come before development can even begin.
Next time you’re watching a movie and a developer is called upon to rapidly deploy a fix, question the reality of the situation. The absence of testing their work means they may have just averted the immediate danger, but have probably created a tonne of new issues in the process due to their lack of quality assurance.
Do you need some support with your website maintenance? Here at Evoluted we offer a range of web development services and would love to find out more about how we can support you further.
With more than two decades’ coding experience under his belt, Senior Developer Andy continues to prove an integral part of the Evoluted development team. Having been with Evoluted since 2012, he has worked on countless projects for our clients. An analytical thinker, his background includes time spent working as a theoretical physicist; which involved research into Quantum Optics.
