<story><title>Ask HN: CS papers for software architecture and design?</title><text>Can you please point me to some papers that you consider very influential for your work or that you believe they played significant role on how we structure our software nowdays?</text></story><parent_chain><item><author>Maro</author><text>I used to be very interested in Software Architecture, in fact I&amp;#x27;ve read many of the papers cited here.&lt;p&gt;When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product&amp;#x2F;customer side of it.&lt;p&gt;The last couple of years I&amp;#x27;ve been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.&lt;p&gt;So, while I&amp;#x27;m not saying that software architecture is not important (it is), also pay attention to the product&amp;#x2F;customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A&amp;#x2F;B tests, etc.&lt;p&gt;I think good software engineers are just as much product guys (and data guys) as they are software guys.&lt;p&gt;-&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;scalien&amp;#x2F;scaliendb&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;scalien&amp;#x2F;scaliendb&lt;/a&gt;</text></item></parent_chain><comment><author>Silhouette</author><text>&lt;i&gt;I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.&lt;/i&gt;&lt;p&gt;Facebook has been extremely successful commercially, but I think it&amp;#x27;s dangerous to read too much into how a unicorn like that develops its software, partly because there is survivorship bias at work here, and partly because the most important things Facebook has achieved have relatively little to do with software.&lt;p&gt;Facebook&amp;#x27;s golden goose is the network effect. Once it reached a critical mass of users, it was all but unstoppable. Arguably its most impressive technical feat was achieving enough scalability in its infrastructure that it could keep up with that many users and that much data. That was a remarkable success story by any standard, but while it surely has a software element, no doubt it involved much more than just code.&lt;p&gt;On the other hand, to a first approximation Facebook has had infinite resources for most of its existence. It operates in an online environment where problems can be fixed even in production. And it doesn&amp;#x27;t really do anything that is going to cause catastrophic, unfixable consequences if something does break for a while. That is a list of luxuries that few software development teams enjoy, and what works if you can make those assumptions won&amp;#x27;t necessarily be a good idea if you can&amp;#x27;t.&lt;p&gt;As you say, you do have to pay attention to other factors as well, but there are not many organisations that have as much room to manoeuvre on the software side as Facebook does.</text></comment>
<story><title>Ask HN: CS papers for software architecture and design?</title><text>Can you please point me to some papers that you consider very influential for your work or that you believe they played significant role on how we structure our software nowdays?</text></story><parent_chain><item><author>Maro</author><text>I used to be very interested in Software Architecture, in fact I&amp;#x27;ve read many of the papers cited here.&lt;p&gt;When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product&amp;#x2F;customer side of it.&lt;p&gt;The last couple of years I&amp;#x27;ve been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.&lt;p&gt;So, while I&amp;#x27;m not saying that software architecture is not important (it is), also pay attention to the product&amp;#x2F;customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A&amp;#x2F;B tests, etc.&lt;p&gt;I think good software engineers are just as much product guys (and data guys) as they are software guys.&lt;p&gt;-&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;scalien&amp;#x2F;scaliendb&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;scalien&amp;#x2F;scaliendb&lt;/a&gt;</text></item></parent_chain><comment><author>Clubber</author><text>Agreed, good architecture doesn&amp;#x27;t come into play until you need to add a lot of complex features or scale significantly. Initially architecture doesn&amp;#x27;t really mean squat. I would concentrate on making the codebase flexible, but that&amp;#x27;s about it. I&amp;#x27;ve regretted making some of my software with a cool but complex architecture when I should have been focused on what the product does.</text></comment>