<story><title>Never use a dependency that you could replace with an afternoon of programming</title><url>https://blog.carlmjohnson.net/post/2020/avoid-dependencies/</url></story><parent_chain><item><author>jdmichal</author><text>My rule is, don&amp;#x27;t use a dependency to implement your core business.  Is JSON parsing our core business?  No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code?  All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions.  Everything else you write is just fat waiting to be cut by someone who knows how to write a business case.&lt;p&gt;To be clear, this is about the &lt;i&gt;lifetime support&lt;/i&gt; of code.  It&amp;#x27;s very, very rare that code can be written once and never touched.  But that long tail of support eats up time and money, and is almost always discounted in these conversations.  I don&amp;#x27;t even care that Jackson JSON parsing has years of work behind it, when I can hack together a JSON parser in a day.  I care that Jackson will &lt;i&gt;continue&lt;/i&gt; to improve their offering without any further input, while that&amp;#x27;s not true of my version.</text></item></parent_chain><comment><author>nayuki</author><text>&amp;gt; don&amp;#x27;t use a dependency to implement your core business&lt;p&gt;In logic language, you&amp;#x27;re saying &amp;quot;If X is your core business, don&amp;#x27;t outsource X&amp;quot;.&lt;p&gt;&amp;gt; Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who knows how to write a business case.&lt;p&gt;The rest of your argument is interpreted as &amp;quot;If X is not your core business, don&amp;#x27;t in-house X&amp;quot;.&lt;p&gt;These two logical implication statements are not equivalents of each other, but are converses. Casual language often conflates If, Only-If, and If-And-Only-If.</text></comment>
<story><title>Never use a dependency that you could replace with an afternoon of programming</title><url>https://blog.carlmjohnson.net/post/2020/avoid-dependencies/</url></story><parent_chain><item><author>jdmichal</author><text>My rule is, don&amp;#x27;t use a dependency to implement your core business.  Is JSON parsing our core business?  No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code?  All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions.  Everything else you write is just fat waiting to be cut by someone who knows how to write a business case.&lt;p&gt;To be clear, this is about the &lt;i&gt;lifetime support&lt;/i&gt; of code.  It&amp;#x27;s very, very rare that code can be written once and never touched.  But that long tail of support eats up time and money, and is almost always discounted in these conversations.  I don&amp;#x27;t even care that Jackson JSON parsing has years of work behind it, when I can hack together a JSON parser in a day.  I care that Jackson will &lt;i&gt;continue&lt;/i&gt; to improve their offering without any further input, while that&amp;#x27;s not true of my version.</text></item></parent_chain><comment><author>xamuel</author><text>Well, one special edge-case would be where you only need to parse some extremely tiny subset of JSON (for example: you only need to parse dictionaries whose keys and values are positive integers, like {1:2,3:4}). Then, depending how expensive the full json parser is, it might be worth your while just writing the limited parser yourself.&lt;p&gt;Of course, you might say, inevitably feature-creep will expand the list of things your parser needs to parse, but that&amp;#x27;s not a law of physics. Sometimes in certain limited, well-defined projects, it really is true that YAGNI.</text></comment>