<story><title>Technical Debt: Why it&apos;ll ruin your software</title><url>https://labcodes.com.br/blog/articles/tech-debt.html</url></story><parent_chain><item><author>spamizbad</author><text>One thing I&amp;#x27;ve learned is that what often looks like overengineering is actually &lt;i&gt;under&lt;/i&gt;engineering -- it&amp;#x27;s much &amp;quot;easier&amp;quot; to throw together a complicated system than really think things through and develop something that accomplishes the same objectives in a simpler (but possibly more &lt;i&gt;complex&lt;/i&gt;) manner.</text></item><item><author>solomatov</author><text>In my experience, I have seen much more problems because of over engineering by well meaning people than because of technical debt.&lt;p&gt;Simple but under engineered systems are much easier to rewrite than to simplify over engineered ones.</text></item></parent_chain><comment><author>hinkley</author><text>A blogger I read when people still did such things asserted that this sort of overengineering is fear. It&amp;#x27;s really dreadfully obvious once you know to look for it.&lt;p&gt;People are so afraid of making a bad decision that they refuse to make any decision at all, and then make a giant mess in the process. What you should do is spend your energy on finding reversible decisions, and then not spend a lot of effort on actually making them. We know where the paint store is, we know they can make up paint in 15 minutes, fuck it, paint it blue, we can always paint over it later. Hard no to black, though, since you can&amp;#x27;t paint over that shit.&lt;p&gt;People are so used to avoiding decisions that on a few occasions I&amp;#x27;ve entirely flustered someone who wanted to tear into me (sometimes with an audience) but cutting them off and saying, &amp;quot;Yeah that was a mistake, and here&amp;#x27;s how we&amp;#x27;re going to fix it.&amp;quot;  None of them had any idea how to recover from someone saying &amp;quot;I was wrong&amp;quot; and going on to try to fix the problem. I still have a little video in my head of one guy&amp;#x27;s eyes bugging out when he realized what I just said.</text></comment>
<story><title>Technical Debt: Why it&apos;ll ruin your software</title><url>https://labcodes.com.br/blog/articles/tech-debt.html</url></story><parent_chain><item><author>spamizbad</author><text>One thing I&amp;#x27;ve learned is that what often looks like overengineering is actually &lt;i&gt;under&lt;/i&gt;engineering -- it&amp;#x27;s much &amp;quot;easier&amp;quot; to throw together a complicated system than really think things through and develop something that accomplishes the same objectives in a simpler (but possibly more &lt;i&gt;complex&lt;/i&gt;) manner.</text></item><item><author>solomatov</author><text>In my experience, I have seen much more problems because of over engineering by well meaning people than because of technical debt.&lt;p&gt;Simple but under engineered systems are much easier to rewrite than to simplify over engineered ones.</text></item></parent_chain><comment><author>coddle-hark</author><text>I think poorly engineered is a better term than under engineered in this case, but I agree with you.&lt;p&gt;Logging is my go-to example for this sort of behaviour. People write stupid amounts of log statements in their code, so much that it’s hard to even read the code to understand what it does, in the hopes that it’ll make debugging easier. Use a damned debugger! Take a traffic dump! Use strace!&lt;p&gt;What’s more, it’s extremely rare that libraries provide logs themselves. So the actual complex parts of your application, like say the HTTP library or (God forbid) the TCP stack, can’t be debugged this way.&lt;p&gt;If you find yourself writing a bunch of statements like “DEBUG: updating balance from 1 to 2”, stop and write some tests instead.</text></comment>