<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Tech Debt on Brave New Geek</title><link>https://bravenewgeek.com/tag/tech-debt/</link><description>Recent content in Tech Debt on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 09 Oct 2024 16:24:56 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/tech-debt/index.xml" rel="self" type="application/rss+xml"/><item><title>Security, Maintainability, Velocity: Choose One</title><link>https://bravenewgeek.com/security-maintainability-velocity-choose-one/</link><pubDate>Wed, 17 Apr 2024 11:41:24 -0600</pubDate><guid>https://bravenewgeek.com/security-maintainability-velocity-choose-one/</guid><description>&lt;p&gt;There are three competing priorities that companies have as it relates to software development: security, maintainability, and velocity. I’ll elaborate on what I mean by each of these in just a bit. When I originally started thinking about this, I thought of it in the context of the “good, fast, cheap: choose two” &lt;a href="https://en.wikipedia.org/wiki/Project_management_triangle"&gt;project management triangle&lt;/a&gt;. But after thinking about it for more than a couple minutes, and as I related it to my own experience and observations at other companies, I realized that in practice it’s much worse. For most organizations building software, it’s more like security, maintainability, velocity: choose &lt;em&gt;one&lt;/em&gt;.&lt;/p&gt;</description></item><item><title>Writing Good Code</title><link>https://bravenewgeek.com/writing-good-code/</link><pubDate>Tue, 07 Apr 2015 19:50:38 -0500</pubDate><guid>https://bravenewgeek.com/writing-good-code/</guid><description>&lt;p&gt;There’s no shortage of people preaching the importance of good code. Indeed, many make a &lt;a href="http://cleancoder.com"&gt;career of it&lt;/a&gt;. The &lt;a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882"&gt;resources&lt;/a&gt; available are equally endless, but lately I’ve been wondering how to extract the essence of building high-quality systems into a shorter, more concise narrative. This is actually something I’ve thought about for a while, but I’m just now starting to formulate some ideas into a blog post. The ideas aren’t fully developed, but my hope is to flesh them out further in the future. You can talk about design patterns, abstraction, encapsulation, and cohesion until you’re blue in the face, but what is the &lt;em&gt;essence&lt;/em&gt; of good code?&lt;/p&gt;</description></item></channel></rss>