<story><title>Malleable Systems: Software must be as easy to change as it is to use it</title><url>https://malleable.systems/</url></story><parent_chain><item><author>saagarjha</author><text>I don&amp;#x27;t think this is a very popular opinion, but for those shipping software, consider having at least one programmatic way to &amp;quot;monkey patch&amp;quot; it. These are things like a plugin API, dynamically linking it, or using a language with an exposed runtime–things that allow programmatic injection of code, so that users who &lt;i&gt;really&lt;/i&gt; care about tweaking the tool can do so. It doesn&amp;#x27;t even take much effort, either: my text editor has no plugin interface, but one of the reasons I stick with it is because I can hook its calls to libc to customize some of the things I don&amp;#x27;t like. My preferred mail client happens to lack a certain entitlement that most people don&amp;#x27;t even know about and that enables an entire cottage industry of software for it. Browsers let you specify some JavaScript to run on each page and suddenly the balance of power on the web tilts significantly towards the user. Even (or especially) if your tool is open source, consider supporting such an interface: it&amp;#x27;s much nicer to add on to piece of software than fork it.</text></item></parent_chain><comment><author>bcrosby95</author><text>The problem is support.  Even if you put big caution tape around it, if you break it or change it in a way that isn&amp;#x27;t backwards compatible users will complain loudly about it.  And if you have users paying lots of $$$ relying on it, it might force your hand.&lt;p&gt;Building a plug-able system in a way that doesn&amp;#x27;t blow up in your face can be hard.  Firefox got a lot of bad press for redesigning their plugin system.</text></comment>
<story><title>Malleable Systems: Software must be as easy to change as it is to use it</title><url>https://malleable.systems/</url></story><parent_chain><item><author>saagarjha</author><text>I don&amp;#x27;t think this is a very popular opinion, but for those shipping software, consider having at least one programmatic way to &amp;quot;monkey patch&amp;quot; it. These are things like a plugin API, dynamically linking it, or using a language with an exposed runtime–things that allow programmatic injection of code, so that users who &lt;i&gt;really&lt;/i&gt; care about tweaking the tool can do so. It doesn&amp;#x27;t even take much effort, either: my text editor has no plugin interface, but one of the reasons I stick with it is because I can hook its calls to libc to customize some of the things I don&amp;#x27;t like. My preferred mail client happens to lack a certain entitlement that most people don&amp;#x27;t even know about and that enables an entire cottage industry of software for it. Browsers let you specify some JavaScript to run on each page and suddenly the balance of power on the web tilts significantly towards the user. Even (or especially) if your tool is open source, consider supporting such an interface: it&amp;#x27;s much nicer to add on to piece of software than fork it.</text></item></parent_chain><comment><author>denster</author><text>¯\_(ツ)_&amp;#x2F;¯&lt;p&gt;Card carrying member of the disagree-club here (malleable clan), but I think it&amp;#x27;s a tall order to ask users to write procedural code.&lt;p&gt;Tools that are:&lt;p&gt;(1) declarative by nature (HTML, DSLs)&lt;p&gt;(2) based on direct manipulation (PSA: we&amp;#x27;re lucky to have Bret Viktor on this planet)&lt;p&gt;is what will win out in my opinion.&lt;p&gt;Or will we be writing procedural code 30, 50 years out? :)&lt;p&gt;--&lt;p&gt;[1] YMMV, founder of &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mintdata.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mintdata.com&lt;/a&gt; here, where we recently opened public access &amp;amp; are seeing the above come true.</text></comment>