The Business Impact of Code Quality
I like where this is going.  Most projects I&#x27;ve been on recently have a &quot;hurry up and get something out&quot; mentality.  Which... I&#x27;m not completely opposed to.  It&#x27;s important to get some early design wins out.  But the flip side of this is as you go on, you learn more about the problem domain and whether specific solutions are appropriate.  You <i>should</i> be okay with throwing out bad code or code that internalizes old requirements that didn&#x27;t survive into the present.<p>I once had a conversation with a &quot;Business Guy&quot; and I brought up the concept of &quot;technical debt.&quot;  Their response was &quot;Oh! Great! We have lots of cash right now and can add more programmers later to pay down the debt, but only if we release something very, very fast!&quot;  -- While the concept of technical debt make sense to me, a software person, the business guy&#x27;s response was &quot;debt is something that can help you if used strategically.&quot;  We changed over to using the phrase &quot;Delivery Molasses&quot; because the more of it you got, the harder it was to move through it.<p>And rather than silently stew about how &quot;business people&quot; don&#x27;t understand software, putting it in terms they understand so you can have a grown-up conversation is worthwhile.  So... happy to see someone&#x27;s doing that here.