Improving diagnostics locally

First off, congratulations on a very well-polished launch! I wasn’t expecting the packaging, the cloud, IDE, etc to be all at the level they are. These things take time to iron out, so problems are inevitable.

After a week or so of playing around with my two cores, I had some thoughts on improving the development experience. Primarily, the long chain of dependencies between the core, cloud, tinker and the web ide is the root cause of spending way more time than is necessary getting the great piece of hardware doing what I want. The design is good, but at this early stage of development, the multi-color blinking LED on the spark isn’t enough.

So, casting some desired features into prioritized “user stories” (

“As a Spark core developer, I want more diagnostic output at the core so I can more quickly determine the cause and solutions to technical issues.”

“As a Spark core developer, I want to develop and download code locally through an established IDE so I don’t have to spend a lot of time struggling with the web IDE on a poor internet connection.”

I’m sure there are many possible implementations to these. Personally, the Arduino IDE with the serial monitor would be great. I’m sure it’s possible and maybe easy to implement, but I’m not a make system guru.

I’m sure there are more than enough things to implement that are more important, but given the existing tech (like the wifi and tcp functionality), I can be implementing lots of cool stuff on these cores, but I’m spending 80+% of my time trying to resolve why I can’t flash from the app or the web IDE or what those blinking lights are really telling me.

1 Like

I agree @ClintonKeith. The level of thought and effort that has gone into the release is impressive. I dip my hat in respect, team SparkCore.

So, as a SparkCore developer, I want a one-line sentence for known bugs and traps in one place so I can digest it quickly and don’t feel so foolish wasting time on known issues.

I fell in to the >2 second loop trap doing a kindergarten level bit of test code getting familiar with the ecosystem, and wasted most of a day narrowing down the problem that was already alluded to somewhere on the forum. People here were kind enough to not to point out that I am an idiot, but that did not stop me going to stand in the corner of the room for a while.

A vibrant community is springing up around here. As it get bigger, I believe it will be important to support the people that don’t normally speak up so they remain engaged.


@ClintonKeith and @nil_orally thanks so much for providing your feedback. The specific tasks that our sprints consist of are driven by user stories formatted exactly like these, so I will literally copy and paste them for our next Sprint Planning meeting that will occur first thing after New Years.

As a member of the manufacturing/operations team, I can’t comment specifically on where these might fall on our software development backlog, but certainly the “most common pitfalls” list could be generated and posted somewhere public relatively quickly. I know that command line and GUI tools for flashing and troubleshooting the are also high on our priority list.

Long story short, your feedback is much appreciated, and I’ll make sure these exact user stories are shared at our next Sprint Planning meeting.

@will Thanks for the feedback! I’m delighted to hear that your team is agile and using user stories and a prioritized backlog. That’s actually something I help video game developers with:

One of the Scrum values is transparency, and it’s been great to see the transparency with Spark development. Additionally, teams similar to yours have had success making their product backlog transparent to their customers. I hope your team considers doing that.


Thanks @ClintonKeith! We’ve also toyed internally with the idea of a public, interactive backlog, but did not have time to reach a decision before the holiday break. In the meantime, I’ve added a +1 for this feature in the #feedback channel of our internal communications tool. We’ll address it, along with your user stories, once we reconvene after the holidays.

We’ve created a blog to publish the results of our sprints, but I understand that you’re talking about a tool for helping us create and prioritize tasks for future sprints.

1 Like

Thanks. I’ll keep an eye on the blog. Most of my clients use Jira for sharing backlogs. If you wanted a fun way to measure customer value for prioritization, I recommend Innovation Games: