<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Engineering Workflows on Nalar</title>
    <link>https://nalar.dev/tags/engineering-workflows/</link>
    <description>Recent content in Engineering Workflows on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 09 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/engineering-workflows/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Building a Walking Skeleton Before Filling In the System</title>
      <link>https://nalar.dev/building-a-walking-skeleton-before-filling-in-the-system/</link>
      <pubDate>Wed, 09 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/building-a-walking-skeleton-before-filling-in-the-system/</guid>
      <description>&lt;p&gt;A team can make steady progress inside individual components and still discover late that the system does not work as a whole. The application starts differently in production, two modules disagree about a contract, a deployment is missing configuration, or the real request path was never exercised until several weeks of work depended on it.&lt;/p&gt;&#xA;&lt;p&gt;A &lt;strong&gt;walking skeleton&lt;/strong&gt; is a small, working path through the system that connects the important architectural pieces before those pieces contain much functionality. It does not prove that the product is complete. It proves that a thin version of the system can travel from an external entry point, through the chosen boundaries, to an observable result.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Feature Flags Need a Removal Plan</title>
      <link>https://nalar.dev/feature-flags-need-a-removal-plan/</link>
      <pubDate>Wed, 09 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/feature-flags-need-a-removal-plan/</guid>
      <description>&lt;p&gt;A feature flag can make a risky change easier to release. You deploy both the old and new behavior, choose which one runs at runtime, and change that choice without rebuilding the application.&lt;/p&gt;&#xA;&lt;p&gt;The same mechanism creates a maintenance problem. Every flag adds another condition the code may execute under. If the flag remains after the decision is settled, developers must keep reasoning about behavior that no longer needs to be optional.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
