Make It Ephemeral: Software Should Decay and Lose Data

This was an excellent read and it resonates with me a lot.<p>I have written here before[1] about the tyranny of &quot;read it later&quot; apps and how liberating it felt to ditch them and move to a &quot;read it now or read it never&quot; (RINORIN) mindset.<p>Although this articles talks about digital ephemera in different contexts such as shared spaces, wikis, runbooks etc., I believe the underlying idea is the same.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41991376">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41991376</a>

It&#x27;s already ephemeral and decays by itself.<p>Honestly as a polyglot, only a Go project can run without being touched for 5 years.<p>The rest of them get vulnerabilities discovered in the packages, which requires you to upgrade, which changes the feature set and takes re-work.<p>Also design ages, UX paradigms change over time, look at the &quot;web 2.0&quot; look today and the &quot;web 1.0&quot; of before. Skeuomorphic design aged as fast as Garage and Jungle music did in the 90s. This will be the same with flat design and neuomorphic design in 5-10 years, if there is even an UI then.<p>All in all, software does decay and we lose data every day. Try go through your oldest bookmarks, many sites will be gone. Or run software that used to run on windows 98 or DOS or amiga or classic mac, you need to jump through hoops, the UX will be terrible, that&#x27;s aging.<p>Software doesn&#x27;t need artificial aging, it erodes well all by itself. Even fast moving code in a startup changes so much from week to week, your merges can be difficult. That&#x27;s like a river bed redefining itself during a rain storm.<p>As humans go through time, so does software as an extension.

The physical world does impose itself on software in some ways. Software is prone to going out of fashion, becoming disused and unmaintained, and eventually forgotten. Peering at a long dead document format in a hex editor is the digital equivalent of wiping dust and grime from the wall of a forgotten tomb.

I don&#x27;t think I could disagree more. He compares software to &quot;the physical world&quot;, but photos in photo albums don&#x27;t just disappear because they get old, and if I put something in a filing cabinet I know it&#x27;ll be there in 1 year or 10 years.

What are some concrete examples of this?<p>- Linear automatically cancels tickets which haven&#x27;t been touched in 6 months<p>- Trello would visually &quot;age&quot; cards, making them increasingly yellow and tattered<p>- Datadog dashboards have a &quot;popularity&quot; score based on usage

For this reason, my browser&#x27;s Downloads folder is &#x2F;tmp.

&gt; I&#x27;m referring to making a deliberate design decision to discard data at a later time. I&#x27;m willing to bet that your cloud storage or SaaS applications likely serve as dumping grounds for outdated, forgotten files and artifacts. This doesn’t have to be the case.<p>IMO there is no way to do this programmatically that satisfies all of your users. What the author describes is organizational debt, and the only way to deal with it effectively is to have the organizational will to periodically clean up that debt. It&#x27;s not easy, and any shortcut comes with it&#x27;s own drawbacks (see corporate data retention policies that inevitably nuke documentation or context).

Decay and losses are just two of the many constraints that could be mixed like paints to create new systems.<p>Limitations, artificial or not, are not always bad. Walls, for example, can be seen as limitation or protection depending on how it&#x27;s used.

Thought about this. I agree 100%. The incumbent belief in software that machines should always remember (embedded in postgresql logo for example) has a dystopian sense of inmortality desires.<p>I would like to play with the idea of a filesystem layer solution that tiers out information based on staleness. The closest I&#x27;ve seen to this is AWS S3 tiers, you&#x27;ve got standard S# at 2.2 cents per GB month, then infrequent, then glacier and some tiers in between.

Methinks the mindfulness cult has gone too far

That&#x27;s a very feel-good &quot;why&quot; that doesn&#x27;t answer on &quot;how&quot;, which is 99% of the work. How exactly do you select what to forget?

I mean, retention policies exist.

This is a strange and awful take. Physical objects decay to the fundamental forces of nature, but that is a flaw, not something we should emulate.<p>Software is a tool. Software is infrastructure. Degradation is desirable in neither.<p>Data has metadata - creation time, access time, etc. - that can power workflows to identify and deal with old data if that is desirable, but in most cases they are not desirable. I haven&#x27;t looked at the directory full of my wedding pictures in a decade, but I don&#x27;t want my photo editing software to decide they&#x27;re irrelevant and delete or hide them.<p>Having access to old documents and data is often important and beneficial. It&#x27;s why people look at inscriptions in old books, why they keep photo albums, why finding a forgotten item when moving furniture can be delightful. It&#x27;s why we&#x27;re able to identify trends.<p>Most crucially, it is incredibly difficult to predict in advance which data will be useful in the future. Proactively discarding things when storage is incredibly cheap is a net negative.