<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>QuACS</title>
    <link>https://quacs.tech/</link>
    <description>Recent content on QuACS</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 18 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://quacs.tech/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Testing a data migration nobody should notice: part 1 — the problem</title>
      <link>https://quacs.tech/articles/ai-in-practice/data-migration-pipeline-part1/</link>
      <pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/ai-in-practice/data-migration-pipeline-part1/</guid>
      <description>&lt;p&gt;The goal of a successful data migration is invisibility. The customer sends a request, gets a response, and has no idea that the system serving that response changed entirely underneath. No missing fields, no value drift, no subtle differences in how arrays are ordered or how dates are formatted. Identical, for all practical purposes, to what came before.&lt;/p&gt;&#xA;&lt;p&gt;That is a harder problem than it sounds.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-the-tests-already-covered&#34;&gt;What the tests already covered&lt;/h2&gt;&#xA;&lt;p&gt;This was an API project with a proper test suite. Unit tests covered the logic layer. Integration tests covered the connections between components. Functional tests covered the behaviour of the endpoints — correct status codes, correct error handling, correct JSON structure. The new system passed all of them.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Working MVP in 90 minutes — Lovable, Anthropic API, and knowing what you want to build</title>
      <link>https://quacs.tech/articles/ai-in-practice/mvp-90-minutes-lovable-claude/</link>
      <pubDate>Fri, 17 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/ai-in-practice/mvp-90-minutes-lovable-claude/</guid>
      <description>&lt;p&gt;There is a version of this story that is about speed. Ninety minutes, working app, Claude API, impressive. That version is true but it is not the interesting part.&lt;/p&gt;&#xA;&lt;p&gt;The interesting part is what happened before I opened Lovable.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-the-app-does&#34;&gt;What the app does&lt;/h2&gt;&#xA;&lt;p&gt;The app analyses CVs against job listings. You paste in a PDF of your CV, paste a link to a job listing, and it does four things: extracts the requirements, company name, salary range and URL from the listing; analyses how well your CV matches; scores the match from 0 to 100; and asks you on a scale of 1 to 10 how much you want to tailor your CV for this role.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Shift-left-left: quality starts when you walk through the door</title>
      <link>https://quacs.tech/articles/processes-and-procedures/shift-left-left/</link>
      <pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/processes-and-procedures/shift-left-left/</guid>
      <description>&lt;p&gt;You have heard of shift left. Test earlier, catch issues sooner, move quality upstream in the development lifecycle. It is good advice and it works. But there is a version of it that goes further — further left than requirements, further left than design, further left than the first conversation about a feature.&lt;/p&gt;&#xA;&lt;p&gt;I call it shift-left-left. And it starts when you walk through the door in the morning.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-team&#34;&gt;The team&lt;/h2&gt;&#xA;&lt;p&gt;The team I am thinking of was not dysfunctional. Everyone was skilled. Everyone had experience — some from large enterprises, some from startups, some from agencies. That was precisely the problem.&lt;/p&gt;</description>
    </item>
    <item>
      <title>We do Scrum. We have dailies.</title>
      <link>https://quacs.tech/articles/processes-and-procedures/scrum-retro/</link>
      <pubDate>Tue, 24 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/processes-and-procedures/scrum-retro/</guid>
      <description>&lt;p&gt;Every team does Scrum. Just ask them.&lt;/p&gt;&#xA;&lt;p&gt;They have dailies. They have a board with columns. Someone, at some point, read the Scrum Guide or at least the first three pages of it. There are sprints, there are planning sessions, there are backlogs with varying degrees of grooming. It&amp;rsquo;s Scrum. Definitely Scrum.&lt;/p&gt;&#xA;&lt;p&gt;There is, however, one event that keeps disappearing — not dramatically, just quietly slipping until the last retrospective was Q3 and it is now Q1 of the following year.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Scrum adoption that actually worked — and why</title>
      <link>https://quacs.tech/articles/processes-and-procedures/agile-success-management/</link>
      <pubDate>Fri, 20 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/processes-and-procedures/agile-success-management/</guid>
      <description>&lt;p&gt;Most agile transformation stories follow the same arc: consultants arrive, workshops happen, a Jira board gets created, and six months later everyone is doing standups but nothing has fundamentally changed. This is not that story.&lt;/p&gt;&#xA;&lt;p&gt;This one worked. And the reason it worked was not what anyone expected.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-team-before&#34;&gt;The team before&lt;/h2&gt;&#xA;&lt;p&gt;Twelve people. A mix of developers, a couple of testers, one product owner who was also doing three other jobs. The process was a generous description — work arrived via email, Slack, and occasionally someone standing at a desk. Priorities changed weekly, sometimes daily. There was a backlog in the sense that there was a spreadsheet that everyone had stopped trusting. Deadlines were set by stakeholders based on feeling rather than capacity. The team was not bad. They were just working in permanent reaction mode.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Postman, Newman, and a little bash to make it useful</title>
      <link>https://quacs.tech/articles/quality-assurance/postman-newman-bash-reporting/</link>
      <pubDate>Thu, 12 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/quality-assurance/postman-newman-bash-reporting/</guid>
      <description>&lt;p&gt;Most teams write Postman collections, run them manually, and call it a day. This is about taking that collection out of the GUI and into a pipeline — with a bash wrapper that makes the output readable for everyone, not just the person who ran it.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-problem-with-just-running-newman&#34;&gt;The problem with just running Newman&lt;/h2&gt;&#xA;&lt;p&gt;Newman works out of the box. You install it, point it at a collection, it runs. But the default output is noisy, exits with a non-zero code on failure without telling you much, and gives you nothing useful to share or log.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The course industrial complex</title>
      <link>https://quacs.tech/articles/thoughts/course-industrial-complex/</link>
      <pubDate>Sun, 02 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://quacs.tech/articles/thoughts/course-industrial-complex/</guid>
      <description>&lt;p&gt;Around 2019, if you spent any time on social media, you could not avoid them. Boot camps, coding tutorials, ebooks with titles like &amp;ldquo;From Zero to Developer in 12 Weeks,&amp;rdquo; video courses promising a career change by the end of the month. They were everywhere — in ads, in newsletters, in the bios of people who had learned to code six months earlier and were now teaching others to do the same.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
