<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>software architecture on Eric Hotinger</title>
    <link>https://ehotinger.com/categories/software-architecture/</link>
    <description>Recent content in software architecture on Eric Hotinger</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sat, 08 Apr 2023 19:32:20 -0700</lastBuildDate>
    <atom:link href="https://ehotinger.com/categories/software-architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Engineers Must Own Quality</title>
      <link>https://ehotinger.com/blog/engineers-must-own-quality/</link>
      <pubDate>Sat, 08 Apr 2023 19:32:20 -0700</pubDate>
      <guid>https://ehotinger.com/blog/engineers-must-own-quality/</guid>
      <description>Why Quality &amp;amp; Assurance Teams are Not Enough: Engineers Must Take Responsibility Engineers must own the quality of the code that they write. Typical quality &amp;amp; assurance teams do not reinforce correct ownership.&#xA;As engineers, our job is to push for quality. We&amp;rsquo;re the only ones that are close enough to the code to understand the shortcuts we&amp;rsquo;re taking, what problems we&amp;rsquo;re creating for the future, and what issues may happen down the road as a result of our actions.</description>
    </item>
    <item>
      <title>The Most Important Software Documentation</title>
      <link>https://ehotinger.com/blog/the-most-important-software-documentation/</link>
      <pubDate>Tue, 17 Jan 2023 07:45:40 -0800</pubDate>
      <guid>https://ehotinger.com/blog/the-most-important-software-documentation/</guid>
      <description>The most important documentation in software engineering is the rationale behind architectural decisions and critical components. This rationale is should be discussed and recorded in a document via design meetings. The design document should contain architectural options which list off pros/cons. The document should have an opinion on the preferred approach and tell the reader why it is the preferred approach.&#xA;Ideally, the design discussions are also recorded and any feedback is persisted into the architectural design document.</description>
    </item>
  </channel>
</rss>
