Josiah Renaudin: Welcome back to another TechWell interview. Today I’m joined by Sam Kaufman, the founder and CTO of BugReplay. Sam, thanks so much for joining me today. First, could you tell us a bit about your experience in the industry?
Sam Kaufman: Thanks, good to be here. I’ve worked in web development for around twelve years now, primarily as a developer and manager. Throughout that time I’ve developed a very healthy respect for QA and the QA process, especially for programmers who work on software and have to deal with bugs quickly.
Josiah Renaudin: Let’s start here: Do you think the average software team takes bug reporting seriously enough? Because it’s so easy to quickly update applications, do most people think it’s OK to ship something with a high volume of bugs?
Sam Kaufman: I think the average company does not take bug reporting seriously, as you can see if you’ve ever tried to report a website problem and couldn’t find any ways on a website to submit feedback or contact a person who could make a fix. Typically, most shops will discount how many users will simply stop using their product because of a bug rather than making them jump through the hoops of reporting a problem. As for shipping products with bugs, I do see that mentality a lot, of shipping first to meet a deadline and fixing problematic issues later. It shouldn’t be that way, but the race to release something new takes precedence over the need to have all flaws ironed out.
Josiah Renaudin: Because people so quickly bounce off of applications or services that don’t stack up to the competition, could you argue that bug reporting is actually more important than ever before?
Sam Kaufman: Absolutely. If you’ve got a faulty product, there is a large likelihood your users will just go elsewhere instead of taking the time and effort to tell you about a problem they’re experiencing. By making it as easy as possible for your users to reach out to you and give you the information you need to fix an issue, you create value for your company in a much more substantial way than competing on features. In other words, showing that you actually care about your customers and their experience using your software is definitely a way to stand out from the crowd today.
Josiah Renaudin: What would you consider “traditional bug reporting,” and what can we do to make it less complicated and labor-intensive than it currently is?
Sam Kaufman: In short, the process of writing a truly useful bug report is long and tedious and can be very frustrating. A traditional bug reporting workflow usually goes something like: a user encounters a problem that they are pretty sure is a bug. They send an email describing the issue from their perspective, which is accurate on their end but most often is technically vague like, “Hey the photo gallery page is broken, any idea when that will get fixed?” A dedicated support person will review the email and respond asking for more details, such as the specific webpage they are viewing, whether or not they can attach a screenshot of the problem, what time/times did the problem occur, and what browser and operating system they are using, among other details. At this point, the support person still does not know what the issue is that the user is seeing and also does not know what information the developers will need to diagnose it.
Josiah Renaudin: Do agile and DevOps practices help people find (and fix) bugs more quickly? Or does the rapidity of agile make it even more difficult to keep up with bugs?
Sam Kaufman: Agile is definitely a double-edged sword in regards to bugs. Just the name says a lot about the actual goal, which is shipping a lot of software, fast. There’s simply no way to ship software fast without also shipping bugs. For example, if you look at the Chromium project’s changelog, each release is packed with bug fixes, meaning that the previous releases introduced bugs that merited fixing despite the fact that they place a high priority on unit and automated testing. Rapid development is why a lot of agile shops do focus on writing tests, which do go a long way towards catching bugs before they hit production.
In terms of DevOps, the new wave of software for application performance monitoring, such as New Relic and Sentry, definitely is helping find anomalies quickly in software releases.
Josiah Renaudin: What about the current DevOps landscape most excites you? Where do you see the biggest benefits for teams?
Sam Kaufman: I’m a big fan of the “serverless” trend, where you upload software to a service and the platform manages the deployment onto an actual server. It always makes me uneasy when systems administration is performed by non-technical people, so the tradeoff of having Google or Amazon manage your servers, virtual or otherwise, so you can just concentrate on writing code is really amazing.
Josiah Renaudin: What about DevOps can be better, and where do you see it going in the next three to five years?
Sam Kaufman: I’d love to see DevOps have more fine-tuned control over every aspect of the security settings for application software. Some of the key security issues can be addressed via containers but they’re not used nearly frequently enough for those purposes.
Josiah Renaudin: At your company, have you found that people you work with have varied definitions of what DevOps even is? Can it be difficult to get on the same page?
Sam Kaufman: Yes, pretty much everyone has a different working definition of DevOps. It’s definitely taken on a buzzwordy connotation that can make it difficult to have discussions about who’s responsible for what. I define DevOps primarily as a set of automation tools that are designed, if not implemented, by Ops teams that let developers contribute and share much of the work that was traditionally done by Ops teams.
Josiah Renaudin: To close things out, what is BugReplay doing to accelerate app delivery? What makes your solution so effective and how can people get their hands on it?
Sam Kaufman: BugReplay makes the feedback cycles between frustrated users and development teams much smaller, and eliminates most of the time and tediousness of sending and receiving bug reports. The ability to capture detailed information about a problem when a user is first reporting an issue makes diagnosing and repairing problems much easier and much faster, which leads to more customer and developer satisfaction.
For more information about BugReplay, please visit www.bugreplay.com.
Sam Kaufman is the founder and CTO of BugReplay, a provider of an innovative set of web browser tools that make reporting bugs faster and fixing them easier. Sam taught himself how to write computer programs at the age of fourteen and has worked as a Flash video developer and application development manager for more than a decade for Heavy.com; Takkle, a social network for connecting high school athletes with college coaches (acquired by Alloy Media + Marketing); and Dow Jones. He is also the current CTO for SocialFlow, a software company that increases distribution of owned and earned content across social media platforms. Reach Sam at [email protected], @EdibleEnergy, and on LinkedIn.
Clear Bug reporting is important especially it the bug is originated from a different team and/or customer.
I define 2 categories
* internal, those bug reports can be short without much detail when the testers and developers are close together and it is quite easy to show what is wrong.
* external (outside of development team). Those bug reports need to have much more detail and steps how to reproduce the issue. However, the issues are still often thrown over the fence. This results in a big delay, due the communication to request for more information and logs. Even when the policies are in place, it still will happen.
This is already the case for more than 16 years and It will never change
Great topic, and I'd highly recommend https://bugrem.com as a bug tracker tool
Interesting discussion! Yeah it is true that, bug tracking is attaining more attention as it could severely affect the quality of the product developed. Bad product creates bad impression on the client, and you may even loose the client itself. Even if some clients give you a second chance for revision, as we all know, the cost of fixing a late bug is 100 times more than the cost it takes to resolve the bug in the requirement’s phase itself. And also, it may take a little time to fix the bug, but in majority of cases, finding the bug is the most tedious & time-consuming task. Considering all these facts, many companies usually seeks help from other companies who have good knowledge in the corresponding domain. Nowadays, a lot of companies are providing high quality affordable software testing services for clients belonging to every level; like B2B, B2C, SMBs etc. Expertise should be a key factor under consideration while choosing a testing service provider.