<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Software-Engineering on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/tags/software-engineering/</link>
		<description>Recent content in Software-Engineering on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 09 Mar 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/tags/software-engineering/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>AI Engineering Is Software Engineering</title>
				<link>https://dplabs.tech/blog/ai-engineering-is-software-engineering/</link>
				<pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/ai-engineering-is-software-engineering/</guid>
				<description>&lt;p&gt;There&amp;rsquo;s a tendency to treat AI features as different from other software. Different enough that normal engineering practices don&amp;rsquo;t apply, or apply differently, or can be deferred. This tendency produces AI systems that are unreliable, unobservable, expensive to operate, and difficult to improve.&lt;/p&gt;&#xA;&lt;p&gt;AI systems built with the same engineering discipline as other distributed systems are more reliable, cheaper to operate, and easier to improve. The disciplines aren&amp;rsquo;t different. The application is.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Abstraction Is a Cost, Not a Free Feature</title>
				<link>https://dplabs.tech/blog/abstraction-is-a-cost/</link>
				<pubDate>Mon, 07 Apr 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/abstraction-is-a-cost/</guid>
				<description>&lt;p&gt;Software engineering culture values abstraction. Interfaces, layers, generalization, frameworks — these are treated as inherently good. The more abstract your code, the more flexible and reusable it is.&lt;/p&gt;&#xA;&lt;p&gt;This is partially true and partially a way to build systems that are harder to understand than they need to be.&lt;/p&gt;&#xA;&lt;p&gt;Abstraction has real benefits. It also has real costs. The question is whether the benefits outweigh the costs in a specific context — not whether abstraction is good in the abstract.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Clean Code Is Not About Pretty Code</title>
				<link>https://dplabs.tech/blog/clean-code-is-not-about-pretty-code/</link>
				<pubDate>Mon, 13 Jan 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/clean-code-is-not-about-pretty-code/</guid>
				<description>&lt;p&gt;&amp;ldquo;Clean code&amp;rdquo; has become a proxy for &amp;ldquo;code that looks like the author read Clean Code.&amp;rdquo; Short methods named with specific patterns. Classes that follow certain principles. Comments removed because &amp;ldquo;code should be self-documenting.&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;This misses the point. Clean code is not a style. It&amp;rsquo;s code that manages complexity effectively — that can be understood, changed, and extended without surprising consequences.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-complexity-actually-costs&#34;&gt;What Complexity Actually Costs&lt;/h2&gt;&#xA;&lt;p&gt;Every line of code has carrying costs. It needs to be understood before it can be changed. Changed before it can be trusted. Tested before it can be deployed. These costs compound.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
