<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Architecture on Panditha</title>
    <link>https://panditha.com/tags/architecture/</link>
    <description>Recent content in Architecture on Panditha</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 14 Mar 2026 11:43:26 +1100</lastBuildDate>
    <atom:link href="https://panditha.com/tags/architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>When Flexibility Becomes a Platform Problem</title>
      <link>https://panditha.com/posts/when-flexibility-is-a-problem/</link>
      <pubDate>Sat, 14 Mar 2026 11:43:26 +1100</pubDate>
      <guid>https://panditha.com/posts/when-flexibility-is-a-problem/</guid>
      <description>&lt;p&gt;Recently I reviewed a piece of infrastructure code written by another engineer on our platform team. The implementation itself was good. It was clean, structured, and clearly thought through. The engineer had designed the system in a way that allowed a high degree of flexibility so that different configurations could be defined through variables. From a software engineering perspective, this was a solid approach. Flexible systems are often considered good design because they can adapt to many situations and avoid making assumptions too early. However, as I looked at the design more closely, something about it felt wrong. The issue was not with the code itself, but with the interface it created for the platform. That moment highlighted an important distinction that is easy to miss: the difference between building libraries and building platforms.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
