<story><title>A Theory of Software Architecture</title><url>https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html</url></story><parent_chain><item><author>AnimalMuppet</author><text>&amp;quot;Not too much&amp;quot; is interesting.  If I understand you correctly, you can write &amp;quot;too much software&amp;quot;.  I can think of at least three ways - bad architecture, too little abstraction forcing repetition, and just bad writing.&lt;p&gt;Did you have something else in mind here?</text></item><item><author>jhardy54</author><text>&amp;gt; Use mostly functions, try to make most of them pure.&lt;p&gt;This reminds me of:&lt;p&gt;&amp;gt; Eat food, not too much, mostly plants
&amp;gt;
&amp;gt; -- Michael Pollan&lt;p&gt;My new mantra: Write software, not too much, mostly functions.</text></item><item><author>adamkl</author><text>I spend a lot of time thinking about these sorts of topics (actually, I just taught a 4 hour session yesterday that used most of the terms in this article), working with newer, less experienced developers, and trying to figure how to distill the essence of &amp;quot;architecture&amp;quot; down to something simple that everyone can start with.&lt;p&gt;This is what I’ve started telling people:&lt;p&gt;&lt;i&gt;Use mostly functions, try to make most of them pure.&lt;/i&gt;&lt;p&gt;I think that can get people (even new devs) 80% of the benefits (testability, composability, loose coupling, and the ability to reason about code) of more complicated, prescriptive architectures (Hexagonal, Onion, Ports &amp;amp; Adapters, Clean, etc) with a minimal amount of ramp up.&lt;p&gt;Of course, this isn&amp;#x27;t the solution to every problem (it obviously depends on the domain you are working in, for me its webDev and backends), but I think maybe its a good way for people to start.&lt;p&gt;Edit: Here is a great talk demonstrating that by following a simple functional approach, your code can naturally fall into a “pit of success”:  &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;US8QG9I1XW0&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;US8QG9I1XW0&lt;/a&gt;</text></item></parent_chain><comment><author>klenwell</author><text>NIH or Resume-Driven Development might be another way.&lt;p&gt;From personal experience, I worked with a team years ago where product owners wanted a datetime picker or parser for an app we had built. Senior dev on team decided it would be cool if it included some lite NLP. When product owners heard from him how easy it would be to add, they were on board.&lt;p&gt;He started with a popular existing Python library. But there was a bug with one corner case that was causing problems. So he took the initiative to spend a few extra days on the story to write his own simple NLP date parser.&lt;p&gt;A couple months later, early on Jan 1st, the new feature wished our ops team Happy New Year by taking down our application.&lt;p&gt;I happened to open an issue for the library&amp;#x27;s bug on Github after learning about it from the other dev. The owner there promptly responded to share a simple workaround for the issue. But by that time we already had too much software on our hands.</text></comment>
<story><title>A Theory of Software Architecture</title><url>https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html</url></story><parent_chain><item><author>AnimalMuppet</author><text>&amp;quot;Not too much&amp;quot; is interesting.  If I understand you correctly, you can write &amp;quot;too much software&amp;quot;.  I can think of at least three ways - bad architecture, too little abstraction forcing repetition, and just bad writing.&lt;p&gt;Did you have something else in mind here?</text></item><item><author>jhardy54</author><text>&amp;gt; Use mostly functions, try to make most of them pure.&lt;p&gt;This reminds me of:&lt;p&gt;&amp;gt; Eat food, not too much, mostly plants
&amp;gt;
&amp;gt; -- Michael Pollan&lt;p&gt;My new mantra: Write software, not too much, mostly functions.</text></item><item><author>adamkl</author><text>I spend a lot of time thinking about these sorts of topics (actually, I just taught a 4 hour session yesterday that used most of the terms in this article), working with newer, less experienced developers, and trying to figure how to distill the essence of &amp;quot;architecture&amp;quot; down to something simple that everyone can start with.&lt;p&gt;This is what I’ve started telling people:&lt;p&gt;&lt;i&gt;Use mostly functions, try to make most of them pure.&lt;/i&gt;&lt;p&gt;I think that can get people (even new devs) 80% of the benefits (testability, composability, loose coupling, and the ability to reason about code) of more complicated, prescriptive architectures (Hexagonal, Onion, Ports &amp;amp; Adapters, Clean, etc) with a minimal amount of ramp up.&lt;p&gt;Of course, this isn&amp;#x27;t the solution to every problem (it obviously depends on the domain you are working in, for me its webDev and backends), but I think maybe its a good way for people to start.&lt;p&gt;Edit: Here is a great talk demonstrating that by following a simple functional approach, your code can naturally fall into a “pit of success”:  &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;US8QG9I1XW0&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;US8QG9I1XW0&lt;/a&gt;</text></item></parent_chain><comment><author>rsanheim</author><text>I think &amp;quot;Too much software&amp;quot; comes from product and engineers not being willing to say &amp;#x27;no&amp;#x27; to feature requests and product bloat, rather than any sort of strictly technical thing.&lt;p&gt;If your product or tool lacks a clear focus and goal, then the code base will reflect that, and will grow and sprawl endlessly.</text></comment>