<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Engineering - Category - Scruffy Cat Studios</title><link>https://scruffycatstudios.com/categories/engineering/</link><description>Engineering - Category - Scruffy Cat Studios</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Fri, 10 Apr 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://scruffycatstudios.com/categories/engineering/" rel="self" type="application/rss+xml"/><item><title>When Not Fixing a Bug Is the Right Path</title><link>https://scruffycatstudios.com/posts/heathcliff-issue-212-postmortem/</link><pubDate>Fri, 10 Apr 2026 12:00:00 +0000</pubDate><author>Juan Segovia</author><guid>https://scruffycatstudios.com/posts/heathcliff-issue-212-postmortem/</guid><description>Short version: we investigated a faint audio pop in a specific filter sweep scenario, tried a narrowly scoped DSP change, found it caused audible regressions on constrained targets, and concluded the right follow-up is an architectural design spike — not a quick patch.
Why this matters (TL;DR for busy readers) We did the investigation the right way: reproduce first, measure, hypothesize, change, and measure again. When a partial fix regresses real users (or MCU targets), it&amp;rsquo;s better to roll back, document what we learned, and plan a proper architecture change.</description></item></channel></rss>