Skip to content Skip to footer


Solving the debugging dilemma: why we need integration (part 1)

by Sam Mullins, Web Developer, 31 May 2018

Read Time: 5 minutes

Over the years at Redweb we’ve created myriad internal projects designed to improve knowledge, sharing and efficiency. Some have been adopted successfully, whereas some have ended up as 50MB of wasted disk space on a server somewhere. There seemed to be a pattern explaining which project ended up in which state: the apps you had to use were used, the apps you chose to use were forgotten.

So what was it that resulted in these optional apps losing popularity? They often solved a common problem and worked well. I think it mainly comes down to integration.

Why we love integrated tools

Developers often have a lot of things open at once: code editors, multiple browsers, email clients, instant messengers, file explorers, command prompts, spec documents, and so on. Adding yet another thing to this list can tip it into unmanageable territory – and once it’s unmanageable, people will either forget to use the product or simply lose motivation.

One example of how we create a better experience through integration is in Dom’s article ‘Cutting myself some Slack’. Here he covers one of the many Slack integrations he’s created to make testing more efficient and reduce repetitive tasks.

Another great example of an optional development tool seamlessly integrating with software you’re already using is Resharper, a Visual Studio extension that helps developers by suggesting improvements while they code (and much more).

Browsers are also a fantastic place for integrated tools, as we spend a huge amount of time using them. Extensions such as LastPass are way easier to use than non-integrated password management services; they save time and effort, as well as offering the added bonus of increased security.

An idea is born

The Yellow Screen Of Death (YSOD) is the bane of an ASP.Net developer’s life, as well as any Front End Developer (FED) or Quality Assurance Analyst (QA) working with Microsoft’s web framework. This is what we are faced with almost every time something goes wrong.

One problem I noticed was that certain errors cropped up more than once, and would often appear to more than one person in the team. Sometimes months would pass in between these errors appearing, so remembering the steps to fix it was pretty tricky. Of course, keeping a log of these errors would’ve helped but as we mentioned earlier, this would add to the many other priorities being juggled by busy developers. As you can see, this isn’t ideal.

So, I had an idea for a tool that would sit in the background waiting for one of these errors to come up, and if possible, guide the user on how to fix it. The main obstacle to this was having the data on how to solve the problem in the first place – so logging of fixes needed to be very simple.

With all that in mind, I thought about a way to create this solution.

Planning the debugging tool’s behaviours

As web developers we normally encounter server errors in the browser. The preference at Redweb seems to sit largely with Chrome, so we set about making an extension for it.

Below are the stages the Chrome extension would need to handle:

1. The system needed the ability to detect when an error occurs. Chrome extensions can read the page contents and, based on pattern matching, would be able to detect if the current page was a server error. The system would log this error automatically without user involvement.

An image of a server error

2. Next, the system had to be able to detect when a fix has been made, or if a new error has been thrown. This is the stage when user input will be required, featuring notes on how the issue was fixed. This process needed to be as straightforward as possible to minimise the impact on developers’ time. A pop-up on the page seemed to be the most efficient method for this and was intentionally slightly disruptive to prompt the user to write a few words.

A screenshot of a fixed issue

3. Now that the system has data, it can offer the user suggestions when it detects an error that’s been thrown before. As all stack traces won’t be identical, a search index would help to rank the matches. The extension icon shows that possible fixes are available and the best matches would be shown to the user if they want to see them.

Image of a server error extension

4. If the user implements one of the fixes suggested, the extension will detect the fix and prompt the user to explain it. Rather than having to type in another comment, they can simply ‘upvote’ the fix that helped them out. These upvotes can be used to promote the most helpful answers and therefore improve the effectiveness of the extension.

A screenshot depicting fixing a server in error

Implementation and next steps

With a plan in place, it was time to get building. I handed the reins to one of our capable developers, Uchenna. In part 2, he’ll be talking about the Ladebug debugger, the tools and techniques he used to build it, and how we’ve been getting on with it so far. Stay tuned!


Insights straight to your inbox

Sign up now to be the first to know when our experts publish a new article.

Your information helps us monitor and improve our content, we will never share it with anyone else. We only send emails we think you’ll find valuable – you won’t hear from us more than once a week. You can unsubscribe any time.