The evolution of Sprkl for CI: How we listen to your feedback

One of the most important things for us at Sprkl is to constantly improve our product based on our users’ feedback and their needs. We do this by listening to our users, connecting with them, forming ongoing relationships, and open communication.

That’s how we realized that we must develop a tool to support the CI stage, which our users are currently experiencing as a “black box.” (It’s tough to tell what went wrong with changes and conduct code reviews). 

How user feedback can help 

By adopting the PLG strategy, we see our product as the primary driver of user acquisition. That means designing a product with the end users, in our case, the devs themselves, in mind. And distributing that product straight to those same end users. 

Collecting user feedback helps us learn about our developers’ experience integrating Sprkl into their projects. We truly believe that higher user satisfaction drives user acquisition turning users into advocates who hopefully will introduce the product to new users (PLG strategy). 

This article describes how listening and connecting with our users has led us to develop and build Sprkl for CI. 

How and why do we collect feedback

Before we started developing our first product, we conducted hundreds of sessions with potential users, trying to learn their day-to-day development needs. Our goal was to design Sprkl according to their feedback, experience, and essential input. 

Our findings: 

A personal feedback loop is missing 

After listening to hundreds of developers, it was evident that something was missing in modern software development processes. It’s almost bizarre how R&D teams work today. Teams usually work on the same code base. Each developer works on different parts of the application. Yet, whether they pushed code to one microservice or another microservice, they always got the same feedback when logging into APMs. These APMs contain a ton of data, and figuring out relevant feedback and context is complex and takes too much time and effort – an effort most devs simply skip. 

It was evident that a personal feedback loop was missing – but we asked ourselves where we should begin in the development cycle.

Where is the feedback loop most needed?

When we conducted our feedback sessions, we found that most developers claim to write their code locally in an iterative process (code, test, rewrite). And only then push it further to CI and later to production. 

This actually fits well with our PLG approach, as we were looking for minimum barriers to entry. The local environment usually has fewer barriers as the devs can choose which apps they wish to use, and there are no security issues. Or approvals they need to ask for.

This is why we initially decided to support local environments and provide devs with a Personal Observability Platform (POP) and contextual feedback directly in their IDE. Using Sprkl personal feedback, they can ship correct and efficient code while spending less time on debugging, code reviews, and frustrating rework.

But research has its limit: In reality – Personal Observability Driven Development is also crucial in CI

As we continuously connect with our users, asking for feedback, we found that many of our users actually conduct very few checks on new code or code changes locally before proceeding to the CI phase. And the most necessary checks are done in CI as opposed to our initial finding. 

We learned that developers experience a significant challenge in understanding what’s going on and what went wrong once they make their code changes in CI. So we decided to bring Personal Observability CI. We wanted to help developers make their pipelines more observable.

We also learned that Personal Observability could be helpful for code review processes. Everyone knows code review is a lengthy, time-consuming process; it takes time to dig into someone else’s code and understand what’s going on. As a reviewer, it takes a long time to review the code thoroughly and respond promptly. Giving constructive feedback and communicating with other teammates is hard.

Our goal was to provide visibility to help developers and team leads uncover the “black box” of failed tests in CI. And reduce their time going through endless logs and traces to figure out where the issue was and what happened. 

So we developed Sprkl for CI (GitHub Actions)

Based on that critical insight, we recently launched our new version of Personal Observability for CI, currently supporting GitHub Actions.

Sprkl shortens code review and debugging time by providing a focused, personalized report for every Pull Request in your IDE. So you can see deeper into the effects of your code diff, including hidden errors, app ripple effect, performance and security insights, diff coverage and more.

How Sprkl can help: 

Team leads

• Identify issues and understand the context of the pull request before reading a line of code
• Improve team productivity – encourage collaboration among team members, 
• Onboard new team members – see clear views of system architecture and flow traces  

 For devs

• Debug instantly- trace back issues to specific lines of code 
• Iterate quicker – pull backtraces from CI to your IDE, debug, fix and commit again 
• Collaborate easily- communicate with your teammates to understand the context of your diff

Once an issue is discovered you can pull our Jaeger-based traces to your IDE and debug it as if it happened locally. 

This way, you save the time it takes to sift through endless logs, trying to figure out the turn of events. Just think how, instead, you can get traces and code references inside your machine: It’s some kind of magic!

Software Development is an iterative process that should be data-driven. With ODD, you iterate based on data-driven feedback. This feedback should be personal and should come looking for you while coding in the IDE, in CI, or, later on, in production. Ideally, you don’t have to look for data  – the data comes looking for you:)

Conclusion – Observability-Driven Development ODD

We listened to our users’ feedback and developed the next phase – Sprkl for CI which goes along with Sprkl for the IDE to provide personalized, immediate feedback. 

Any feedback? Ping me