<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Zairi Aimen</title>
    <link>https://blog.zairiaimen.com/</link>
    <description></description>
    <pubDate>Mon, 04 May 2026 14:09:25 +0200</pubDate>
    <item>
      <title>The 7 Deadly Sins of Software Engineering</title>
      <link>https://blog.zairiaimen.com/7-deadly-sins-of-software-engineering</link>
      <description>&lt;![CDATA[2025 has been my most interesting year in software development so far.&#xA;&#xA;!--more--&#xA;&#xA;I completed six production projects that now require ongoing maintenance, worked on one long-running project that’s been active since March, and experimented with half a dozen smaller prototypes. Compared to previous years, where I intentionally focused on fewer projects, the sheer volume and variety in 2025 exposed me to failure modes I hadn’t seen as clearly before.&#xA;&#xA;In 2023–2024, work was slower due to a mix of personal and professional circumstances. With stability returning in 2025, I was able to take on more clients and more projects of varying sizes, and that accelerated my learning dramatically.&#xA;&#xA;This article summarizes seven recurring problems I’ve seen either nearly destroy projects or directly cause their cancellation. I call them the 7 Deadly Sins of Software Engineering.&#xA;&#xA;---&#xA;&#xA;1. Pride&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/iCytOfY4vE&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Pride is arrogance disguised as confidence. It’s the belief that assumptions matter more than evidence, and that “we know better” than users, data, or even teammates.&#xA;&#xA;This sin usually appears in one (or both) of two places: management and development. In both cases, the result is the same: a technically solid product that solves the wrong problem.&#xA;&#xA;A. Management Pride (The Ivory Tower)&#xA;&#xA;Leadership assumes they understand the user better than the users themselves. Research is ignored, feedback is dismissed, and decisions are driven by an unvalidated “vision.”&#xA;&#xA;Examples:&#xA;Adding AI to a product that’s still unstable.&#xA;Ignoring user complaints because they conflict with leadership’s beliefs.&#xA;Treating refactoring as “zero-value” work.&#xA;&#xA;B. Developer Pride&#xA;&#xA;Developers prioritize technical purity or intellectual challenge over business outcomes. With little direct user interaction, they end up building software for themselves, not for customers.&#xA;&#xA;Examples:&#xA;Reinventing components instead of using proven libraries.&#xA;Over-engineering simple problems to showcase technical superiority.&#xA;&#xA;---&#xA;&#xA;2. Greed&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/PAnWgrQR698&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Greed is demanding massive results without providing the necessary investment.&#xA;&#xA;Projects are starved of budget, people, and tools, yet expectations keep rising. When this sin is present, failure is almost guaranteed, and the damage is felt immediately across the organization.&#xA;&#xA;Examples:&#xA;Firing an entire team and replacing them with a single “vibe-coder.”&#xA;Expecting a small team to deliver in six months what a larger team couldn’t ship in years.&#xA;&#xA;---&#xA;&#xA;3. Lust&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/-TF1BZuSb4U&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Lust is the uncontrolled desire for more: more features, more tweaks, more “quick wins.”&#xA;&#xA;It’s the seduction of the next cool idea. The roadmap becomes a graveyard of half-finished features, and the original goal slowly disappears.&#xA;&#xA;While related to greed, lust operates at a technical and product level, feature after feature, added without restraint.&#xA;&#xA;Examples:&#xA;Shipping a feature to satisfy a single user without considering system-wide impact.&#xA;Chasing AI integration simply because it’s trendy.&#xA;&#xA;---&#xA;&#xA;4. Sloth&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/jdW9y3htNyY&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Sloth is avoiding the hard, boring, or uncomfortable work that keeps projects healthy.&#xA;&#xA;It shows up as procrastination, corner-cutting, and a culture of “we’ll fix it later.”&#xA;&#xA;Common causes include weak leadership, lack of accountability, and organizations that don’t value quality.&#xA;&#xA;Examples:&#xA;Managers committing experimental code directly to main.&#xA;Skipping tests to “move faster.”&#xA;Endless TODOs and undocumented systems.&#xA;&#xA;---&#xA;&#xA;5. Gluttony&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/LvhjaLsFEuw&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Gluttony is the relentless consumption of development resources to churn out features, while quietly creating an unmaintainable mess underneath.&#xA;&#xA;It feels productive at first. Velocity looks great. But eventually the codebase becomes bloated, fragile, and immobile.&#xA;&#xA;Unlike lust or sloth, gluttony is systematic: features are always prioritized, while maintenance is perpetually deferred.&#xA;&#xA;Examples:&#xA;No time allocated for refactoring.&#xA;Treating automated tests as optional.&#xA;&#xA;---&#xA;&#xA;6. Wrath&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/6g6-yGOXyy8&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Wrath is the anger and resentment born from toxic communication.&#xA;&#xA;Ambiguity, blame culture, and information silos turn collaboration into open conflict. Teams stop working together, and sometimes actively work against each other.&#xA;&#xA;This sin slows projects more than almost anything else.&#xA;&#xA;Examples:&#xA;Managers who reward blame instead of problem-solving.&#xA;Teams that never communicate but still blame each other for failures.&#xA;&#xA;---&#xA;&#xA;7. Envy&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/pT2ZBCTAxs&#34; frameborder=&#34;0&#34; allowfullscreen/iframe&#xA;&#xA;Envy is abandoning your strategy because someone else looks more successful.&#xA;&#xA;Competitors ship something shiny. Another department gets attention. Leadership panics, and direction changes overnight.&#xA;&#xA;This is one of the most destructive sins, and it often feeds directly into wrath.&#xA;&#xA;Examples:&#xA;Replacing a high-performing team for political reasons.&#xA;Constantly pivoting to chase trends instead of executing a long-term vision.&#xA;&#xA;---&#xA;&#xA;Conclusion&#xA;&#xA;These are just seven of many ways a software project can fail, but they’re the ones I see most often.&#xA;&#xA;Avoiding all of them is extremely difficult. However, when there’s real alignment between users, developers, and leadership, the path forward becomes clear.&#xA;&#xA;And when that alignment exists, projects tend to succeed, not by accident, but by design.]]&gt;</description>
      <content:encoded><![CDATA[<p>2025 has been my most interesting year in software development so far.</p>



<p>I completed <strong>six production projects</strong> that now require ongoing maintenance, worked on <strong>one long-running project</strong> that’s been active since March, and experimented with <strong>half a dozen smaller prototypes</strong>. Compared to previous years, where I intentionally focused on fewer projects, the sheer volume and variety in 2025 exposed me to failure modes I hadn’t seen as clearly before.</p>

<p>In 2023–2024, work was slower due to a mix of personal and professional circumstances. With stability returning in 2025, I was able to take on more clients and more projects of varying sizes, and that accelerated my learning dramatically.</p>

<p>This article summarizes <strong>seven recurring problems</strong> I’ve seen either <em>nearly destroy</em> projects or <em>directly cause their cancellation</em>. I call them the <strong>7 Deadly Sins of Software Engineering</strong>.</p>

<hr>

<h2 id="1-pride">1. Pride</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/iCytOf_Y4vE" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Pride</strong> is arrogance disguised as confidence. It’s the belief that assumptions matter more than evidence, and that “we know better” than users, data, or even teammates.</p>

<p>This sin usually appears in one (or both) of two places: <strong>management</strong> and <strong>development</strong>. In both cases, the result is the same: a technically solid product that solves the <em>wrong problem</em>.</p>

<h3 id="a-management-pride-the-ivory-tower">A. Management Pride (The Ivory Tower)</h3>

<p>Leadership assumes they understand the user better than the users themselves. Research is ignored, feedback is dismissed, and decisions are driven by an unvalidated “vision.”</p>

<p><strong>Examples:</strong>
– Adding AI to a product that’s still unstable.
– Ignoring user complaints because they conflict with leadership’s beliefs.
– Treating refactoring as “zero-value” work.</p>

<h3 id="b-developer-pride">B. Developer Pride</h3>

<p>Developers prioritize technical purity or intellectual challenge over business outcomes. With little direct user interaction, they end up building software for themselves, not for customers.</p>

<p><strong>Examples:</strong>
– Reinventing components instead of using proven libraries.
– Over-engineering simple problems to showcase technical superiority.</p>

<hr>

<h2 id="2-greed">2. Greed</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/PAnWgrQR698" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Greed</strong> is demanding massive results without providing the necessary investment.</p>

<p>Projects are starved of budget, people, and tools, yet expectations keep rising. When this sin is present, failure is almost guaranteed, and the damage is felt immediately across the organization.</p>

<p><strong>Examples:</strong>
– Firing an entire team and replacing them with a single “vibe-coder.”
– Expecting a small team to deliver in six months what a larger team couldn’t ship in years.</p>

<hr>

<h2 id="3-lust">3. Lust</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/-TF1BZuSb4U" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Lust</strong> is the uncontrolled desire for <em>more</em>: more features, more tweaks, more “quick wins.”</p>

<p>It’s the seduction of the next cool idea. The roadmap becomes a graveyard of half-finished features, and the original goal slowly disappears.</p>

<p>While related to greed, lust operates at a <strong>technical and product level</strong>, feature after feature, added without restraint.</p>

<p><strong>Examples:</strong>
– Shipping a feature to satisfy a single user without considering system-wide impact.
– Chasing AI integration simply because it’s trendy.</p>

<hr>

<h2 id="4-sloth">4. Sloth</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/jdW9y3htNyY" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Sloth</strong> is avoiding the hard, boring, or uncomfortable work that keeps projects healthy.</p>

<p>It shows up as procrastination, corner-cutting, and a culture of “we’ll fix it later.”</p>

<p>Common causes include weak leadership, lack of accountability, and organizations that don’t value quality.</p>

<p><strong>Examples:</strong>
– Managers committing experimental code directly to <code>main</code>.
– Skipping tests to “move faster.”
– Endless <code>TODO</code>s and undocumented systems.</p>

<hr>

<h2 id="5-gluttony">5. Gluttony</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/LvhjaLsFEuw" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Gluttony</strong> is the relentless consumption of development resources to churn out features, while quietly creating an unmaintainable mess underneath.</p>

<p>It feels productive at first. Velocity looks great. But eventually the codebase becomes bloated, fragile, and immobile.</p>

<p>Unlike lust or sloth, gluttony is <strong>systematic</strong>: features are always prioritized, while maintenance is perpetually deferred.</p>

<p><strong>Examples:</strong>
– No time allocated for refactoring.
– Treating automated tests as optional.</p>

<hr>

<h2 id="6-wrath">6. Wrath</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/6g6-yGOXyy8" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Wrath</strong> is the anger and resentment born from toxic communication.</p>

<p>Ambiguity, blame culture, and information silos turn collaboration into open conflict. Teams stop working together, and sometimes actively work against each other.</p>

<p>This sin slows projects more than almost anything else.</p>

<p><strong>Examples:</strong>
– Managers who reward blame instead of problem-solving.
– Teams that never communicate but still blame each other for failures.</p>

<hr>

<h2 id="7-envy">7. Envy</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/pT2ZBCT_Axs" frameborder="0" allowfullscreen=""></iframe>

<p><strong>Envy</strong> is abandoning your strategy because someone else looks more successful.</p>

<p>Competitors ship something shiny. Another department gets attention. Leadership panics, and direction changes overnight.</p>

<p>This is one of the most destructive sins, and it often feeds directly into wrath.</p>

<p><strong>Examples:</strong>
– Replacing a high-performing team for political reasons.
– Constantly pivoting to chase trends instead of executing a long-term vision.</p>

<hr>

<h2 id="conclusion">Conclusion</h2>

<p>These are just <strong>seven</strong> of many ways a software project can fail, but they’re the ones I see most often.</p>

<p>Avoiding all of them is extremely difficult. However, when there’s real alignment between <strong>users, developers, and leadership</strong>, the path forward becomes clear.</p>

<p>And when that alignment exists, projects tend to succeed, not by accident, but by design.</p>
]]></content:encoded>
      <guid>https://blog.zairiaimen.com/7-deadly-sins-of-software-engineering</guid>
      <pubDate>Mon, 02 Feb 2026 11:16:16 +0100</pubDate>
    </item>
  </channel>
</rss>