<story><title>Write code that is easy to delete, not easy to extend (2016)</title><url>https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to</url></story><parent_chain><item><author>flohofwoe</author><text>The unfortunate side effect of this (very good) advice is that all code that&amp;#x27;s easy to delete will eventually be replaced with code that&amp;#x27;s hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).</text></item></parent_chain><comment><author>hedora</author><text>Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete.&lt;p&gt;They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modularized programs.  None of the collateral damage is in subsystems related to init.  Instead, it is subsystems that worked well, but that were easy to delete.&lt;p&gt;One the other side of the coin, look at all the effort people are spending to rip systemd out.  Multiple Linux distributions exist solely to contain the damage it’s doing.&lt;p&gt;It’s unclear if gnome will even survive the war if systemd loses.&lt;p&gt;It’s also wasting the time of end users, so the damage can greatly exceed the total resources put into building Linux distributions.&lt;p&gt;A few days ago, I ran an “apt-get fullupgade” on my headless Raspberry Pi, and some systemd subsystem wedged during the upgrade.  Now networking is broken.  I want to use this raspberry pi in an embedded I2C application that run for last decades.  So, I need to find an operating system that:&lt;p&gt;(a) doesn’t use systemd - fool me once, shame on you, fool me twice, well this is well past the second time.&lt;p&gt;(b) runs on raspberry pi&lt;p&gt;(c) has userspace tools to work with the i2c bus on the pi&lt;p&gt;(d) has a working upgrade path.&lt;p&gt;This is a huge pain, and it’s all to delete one software package that I don’t even care about, and that is irrelevant to the use case for this machine.&lt;p&gt;&amp;#x2F;rant</text></comment>
<story><title>Write code that is easy to delete, not easy to extend (2016)</title><url>https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to</url></story><parent_chain><item><author>flohofwoe</author><text>The unfortunate side effect of this (very good) advice is that all code that&amp;#x27;s easy to delete will eventually be replaced with code that&amp;#x27;s hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).</text></item></parent_chain><comment><author>snarf21</author><text>I think the one thing we do wrong with code is when we document it, we write &lt;i&gt;what&lt;/i&gt; the function does. Code is largely self-documenting and this because stale quickly anyway.&lt;p&gt;IMO, the thing we should be doing is documenting &lt;i&gt;WHY&lt;/i&gt; this function needs to exist. That is the question that is hard to answer three years later.</text></comment>