The Trouble with Bugs

The debate on bugs and who’s responsible for them within a software or web development project is one that comes up in just about every project of this nature. No matter the project, the agency or the client, bugs come with the territory and are often seen as a “mistake” created by the programming team and therefore that team’s issue to resolve.

A quick history lesson for you: (Because the origin of the term “bug” in software development is a lot more fun than the actual bugs people experience.)

According to an article by Sharron Ann Danis, Rear Admiral Grace Murray Hopper, a computer programmer and strong supporter of COBOL programming language which allowed programmers to speak in words instead of numbers, first coined the term.

The basic story is that in 1946, when Hopper completed her active duty in the Navy, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III early computer calculators. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.

Back to my point now…

The debate on bugs and who’s responsible for them within a software or web development project is one that comes up in just about every project of this nature. No matter the project, the agency or the client, bugs come with the territory and are often seen as a “mistake” created by the programming team and therefore that team’s issue to resolve.

This thought process seems logical and in a sense is true; your dev team SHOULD work to resolve bugs when they occur. While they are a common part of the process and nearly unavoidable at some point in the life cycle of your code, you should be working with a team that can detect, replicate, investigate and resolve bugs as they arise. Some of them are quick fixes that literally take minutes to track down and squish, others can be complex in nature, involve multiple systems within your structure and take some significant brainpower and keyboard cowboying to resolve. Assigning blame may seem like the best way to resolve the “who pays” question but it’s not always straightforward to find the blame and can often be counterproductive to the issue of getting it resolved. Regardless, your team should be ready, willing and able to do what it takes to resolve the issue for you and get your project, site, application...whatever, humming again.

So that covers the physical responsibility of a bug, but what about the financial responsibility? This takes us back to the concept of the “mistake”. The truth is, it comes down to what’s reasonable with relation to each situation. “Thanks for the straightforward answer guys!” is what you’re saying right now, right? We know. The fact is it’s a bit of a complex issue, but we’re going to try to unpack it for you a bit.

The client/agency relationship is just like any other relationship you can think of. In a healthy one, you spend a lot of time doing your due diligence, finding a good, reliable partner who you can trust. You build the relationship over time, get to know each other and both work hard to communicate effectively, get ahead of issues and resolve conflicts when they arise.

I can’t speak for everyone, but here at The Refinery we work really hard to be good partners to our clients. Things don’t always go 100% perfect but we do everything within our ability to rectify wrongs, admit fault when it’s ours, discuss situations that require discussion, and come to a resolution that satisfies everyone. We also pride ourselves on transparency and being kind but direct with clients when they’re in their own way so that we can help them achieve their desired result. We aren’t “yes” men and women, but we are teammates with our clients working hand in hand to deliver projects that do what they are supposed to do and help our clients to achieve their goals.

So let’s assume you’re in a good relationship with your agency and you trust them. You’re getting updates on the project, it’s progressing or launched and then it happens. The bug happens.

As a point of order, the definition of the word “bug” often means different things to different people. Some people think anything that doesn’t work as they intend is a bug, others are more specific about what is and is not a bug. Truth is, whatever you want to call it, if it’s not what you the client want, we need to fix it but again, how and at whose expense?

It is standard practice in the development world that clients pay for bug fixes. That said, there’s a bunch of grey area here and we should highlight some of those more complicated situations.

Bugs can occur for a variety of reasons. Some of them include:

• When a third party provider makes changes to a plugin and creates a malfunction.
• When something doesn’t work as anticipated because of a miscommunication about functionality. To be pedantic, assumptions all too often become miscommunications, and we’re left expecting different results.
• When someone with access to the site (perhaps on the client or client partner side) makes a mistake and “breaks” something by accident
• When the agency team makes a mistake in code or deployment. Yep. I said it, sometimes we just mess up!
• There are lots of other examples of how bugs can happen but that gives you a bit of insight into them.

So getting back to that point about the relationship. The basic truth here is that if it’s something we should have caught, something we should have reasonably accounted for, something our developer coded incorrectly, we’re going to fix it at our cost. As I mentioned before it happens and it’s a natural part of the development process. There are a number of reasons why it happens but when it’s on us, we admit it’s on us. Taking it one step further, most of the time if it’s something no one could have predicted, our project management team is overly fair about crediting time to rectify the issue. We give our project managers latitude to credit billable hours back to the client when it’s the right thing to do BECAUSE it’s the right thing to do. So even when it comes to the financial implications of a bug, we believe in being a team and shouldering the burden to find the solution together including financially within reason.

So how do you know if what you’re experiencing is typical, reasonable, fair?

You’d like to believe you’ve done a good job of finding a good web development or software development partner, but how do you know if your spidey-senses are right? There are some questions you can ask to gauge the situation you find yourself in and the relationship with your agency.

Things like:

• Is this type of bug something you’ve seen before? If so, should you have planned for it better?

• Is it related to my site or the server it’s hosted on? Sometimes this uncovers the need for new hosting or hardware.

• Is it typical to see bugs this frequently on this type of platform? This can be a tough question to answer but often there are certain things that are more common in certain CMS’s and depending on the resulting problem for your business, a change may be in order. We have had this conversation a number of times when “inheriting” a site for a client from a previous developer.

• Are there proactive things we can do to prevent this in the future? Part of this includes asking if they have any maintenance plans that engage them to stay on top of updates, patches, fixes and more to your site. This can be extremely helpful if you don’t have an in-house IT team to manage this for you because plugins update often and as the online world evolves browsers, search engines etc., change their protocols and requirements.

1. The bug is discovered, reported and able to be replicated. If we can’t replicate it, we ask a bunch of annoying questions like what browser you’re on, what device you’re using, what it did, what you saw, if it threw an error code what was it, what phase the moon was in...kidding about the last one but we’re gonna ask a bunch so we can rule out things to try to get to the root cause of the issue.
2. Our team will do some digging so we can get a diagnosis of the issue and your PM will let you know what we find.
3. If it’s a little issue, we fix it and typically don’t charge for it. What’s typical? Our rule of thumb is generally less than 45 min to complete.
4. If it’s a bigger issue, we’ll give you a breakdown of what likely happened and what it’s going to take to fix from a man hours (budget) and timeline perspective.
5. Once we have your blessing, we’ll work on the fix, test the fix (ideally in a staging environment and not live on your site to ensure we protect the rest of the user’s experience) and then deploy the fix to your live site.

We should mention here that sometimes the bug turns out to be related to a plugin or other outside party. In those cases, once identified, we can reach out to the proper development team for a fix, but can’t control how or when they fix it.

Websites and applications are like any other technical or mechanical thing in your life. Breaking is going to happen and it’s gonna need a tune up from time to time.

As we’ve discussed, like ants to a sucker on the sidewalk, bugs on your site are going to happen at some point. How your agency addresses them and fixes them matters. They should be able to diagnose the problem, identify why it happened or offer a reasonable hypothesis if an exact answer isn’t possible, and fix the issue in a reasonable period of time. Key to all of this is that they should be communicating with you throughout the process and working to resolve it.