<story><title>Designing Low Upkeep Software</title><url>https://www.jefftk.com/p/designing-low-upkeep-software</url></story><parent_chain><item><author>hsn915</author><text>People think if a project on github hasn&amp;#x27;t been updated since 3 months then it has been abandoned!!&lt;p&gt;Like, why don&amp;#x27;t we just let projects be &amp;quot;done&amp;quot;? Things don&amp;#x27;t need to be maintained and updated for eternity.&lt;p&gt;In my mind, the best software engineering is where you solve a problem once and your solution just works and needs no configuration or maintenance or updates.&lt;p&gt;This of course has a very low chance of happening if your system has to exist as a part of &amp;quot;ecosystem&amp;quot; where you expect&amp;#x2F;assume the presence of some external service that can change its API on a whim (or just disappear).&lt;p&gt;Yes, to a certain degree it&amp;#x27;s impossible to design software that does not exist as a part of an ecosystem, which is why I put it in quotes.&lt;p&gt;Some APIs are stable and are guaranteed to continue to exist for a very long time: CPU instruction sets, networking protocols (IP&amp;#x2F;UDP&amp;#x2F;TCP), operating systems (AFAICT: Linux (the kernel) works hard to not break user programs, and Windows is kind of known for bending over backwards to maintain compatibility with old programs), file systems, etc.&lt;p&gt;What I&amp;#x27;m advocating for here requires that your program be compiled into a native executable binary file, and it must embed all its library dependencies (aka static linking).</text></item></parent_chain><comment><author>3pt14159</author><text>Unless you&amp;#x27;re doing something mathematical, where you can exhaustively test every input and output and ship something that&amp;#x27;s essentially close to the platonic ideal of the thing, you&amp;#x27;re going to need to update.&lt;p&gt;Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on.&lt;p&gt;It&amp;#x27;s like asking why a person can&amp;#x27;t be just done learning so they can live their life. Well, they can, but pretty soon the world is inaccessible to them. They can&amp;#x27;t use a computer or a phone because they stopped learning in 1995 and they&amp;#x27;re utterly dependant on others to do things for them.&lt;p&gt;But I will say this, I&amp;#x27;ve long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that&amp;#x27;s out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.</text></comment>
<story><title>Designing Low Upkeep Software</title><url>https://www.jefftk.com/p/designing-low-upkeep-software</url></story><parent_chain><item><author>hsn915</author><text>People think if a project on github hasn&amp;#x27;t been updated since 3 months then it has been abandoned!!&lt;p&gt;Like, why don&amp;#x27;t we just let projects be &amp;quot;done&amp;quot;? Things don&amp;#x27;t need to be maintained and updated for eternity.&lt;p&gt;In my mind, the best software engineering is where you solve a problem once and your solution just works and needs no configuration or maintenance or updates.&lt;p&gt;This of course has a very low chance of happening if your system has to exist as a part of &amp;quot;ecosystem&amp;quot; where you expect&amp;#x2F;assume the presence of some external service that can change its API on a whim (or just disappear).&lt;p&gt;Yes, to a certain degree it&amp;#x27;s impossible to design software that does not exist as a part of an ecosystem, which is why I put it in quotes.&lt;p&gt;Some APIs are stable and are guaranteed to continue to exist for a very long time: CPU instruction sets, networking protocols (IP&amp;#x2F;UDP&amp;#x2F;TCP), operating systems (AFAICT: Linux (the kernel) works hard to not break user programs, and Windows is kind of known for bending over backwards to maintain compatibility with old programs), file systems, etc.&lt;p&gt;What I&amp;#x27;m advocating for here requires that your program be compiled into a native executable binary file, and it must embed all its library dependencies (aka static linking).</text></item></parent_chain><comment><author>bArray</author><text>&amp;gt; Like, why don&amp;#x27;t we just let projects be &amp;quot;done&amp;quot;? Things don&amp;#x27;t need to be maintained and updated for eternity.&lt;p&gt;This is generally why I opt for &amp;quot;single-file&amp;quot; libraries that do one simple task well. The smaller the library, the more likely it is &amp;quot;done&amp;quot;. For example, do I want some insanely complex image library that handles every file format under the sun, or do I just want some basic one that allows me to output a simple JPEG?&lt;p&gt;I often find myself referring to &amp;quot;single_file_libs&amp;quot; repository: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;nothings&amp;#x2F;single_file_libs&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;nothings&amp;#x2F;single_file_libs&lt;/a&gt;&lt;p&gt;Looking at the open issues, it doesn&amp;#x27;t appear to be actively maintained but it&amp;#x27;s still an incredibly good resource for &amp;quot;completed&amp;quot; projects.</text></comment>