<story><title>Building data infrastructure that will last</title><url>https://seattledataguy.substack.com/p/why-your-data-stack-wont-last-and</url></story><parent_chain></parent_chain><comment><author>Terr_</author><text>I&amp;#x27;ve come to believe the opposite, promoting it as &amp;quot;Design for Deletion.&amp;quot;&lt;p&gt;I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody, and they&amp;#x27;re going to be justified demolishing the whole mess, no matter how proud I may feel about it now.&lt;p&gt;So instead, put effort into making it &lt;i&gt;easy to remove&lt;/i&gt;. This often ends up reducing coupling, but--crucially--it&amp;#x27;s not the same as some enthusiastic young developer trying to decouple &lt;i&gt;all the things&lt;/i&gt; through a meta-configurable framework. Sometimes a tight coupling is better when it&amp;#x27;s easier to reason about.&lt;p&gt;The question isn&amp;#x27;t whether You Ain&amp;#x27;t Gonna Need It, the question is whether when you &lt;i&gt;do&lt;/i&gt; need it will so much have changed that other design-aspects won&amp;#x27;t be valid anymore. It also means a level of trust towards (or helpless acceptance of) a future steward of your code.</text></comment>
<story><title>Building data infrastructure that will last</title><url>https://seattledataguy.substack.com/p/why-your-data-stack-wont-last-and</url></story><parent_chain></parent_chain><comment><author>weego</author><text>&lt;i&gt;How do you ensure the data infrastructure you’re building doesn’t get replaced as soon as you leave in the future?&lt;/i&gt;&lt;p&gt;If this is a core conceit of the thinking then my answer is who cares?&lt;p&gt;Why do you want to try and influence a situation you&amp;#x27;re not even involed in?&lt;p&gt;Taking it back to the best lesson I was ever given in software engineering &amp;quot;don&amp;#x27;t code for every future&amp;quot;.&lt;p&gt;Do what you&amp;#x27;re asked to and not get caught up in projecting your own biases into trying to make a &amp;quot;solid base&amp;quot; for the future when you can&amp;#x27;t know the concerns of said future.</text></comment>