<story><title>Does it scale? Who cares (2011)</title><url>https://jacquesmattheij.com/does-it-scale-who-cares</url></story><parent_chain><item><author>shadowmint</author><text>I care.&lt;p&gt;It&amp;#x27;s easy to brush off scaling concerns as not important, but I&amp;#x27;ve had personal experience where it&amp;#x27;s mattered, and if you want a high profile example, look at twitter.&lt;p&gt;Yes, premature optimization is a bad thing, and so is over engineering; but that&amp;#x27;s easy to say &lt;i&gt;if&lt;/i&gt; you have the experience to make the right initial choices that mean you have a meaningful path forward &lt;i&gt;to scale&lt;/i&gt; when you do need it.&lt;p&gt;For example, lets say you build a typical business app and push something out quickly that doesn&amp;#x27;t say, log when it fails, or provide an auto-update mechanism, or have any remote access. Now you have it deployed at 50 locations and its &amp;#x27;not working&amp;#x27; for some reason. Not only do you physically have to go out to see whats wrong, you have to organize a reinstall at 50 locations. Bad right? yes. It&amp;#x27;s very bad. (&amp;lt;---- Personal experience)&lt;p&gt;Or, you do a similar ruby or python app when your domain is something that involves bulk processing massive loads of data. It works fine and you have a great &amp;#x27;platform&amp;#x27; until you have 3 users, and then it starts to slow down for everyone; and it turns out, you need a dedicated server for each customer because doing your business logic in a slow language works when you only need to do 10 items a second, not 10000. Bad right? yes. Very. Bad. (&amp;lt;---- Personal experience)&lt;p&gt;It&amp;#x27;s not premature optimization to not pick stupid technology choices for your domain, or ship prototypes.&lt;p&gt;...but sometimes you don&amp;#x27;t have someone on the team with the experience to realize that, and the push from management is to just get it out, and not worry about the details; but trust me, if you have someone who is sticking their neck out and go, hey wait, this isn&amp;#x27;t going to scale...&lt;p&gt;Maybe you should listen to what they have to say, not quote platitudes.&lt;p&gt;Ecommerce is probably one of those things where the domain is well enough known you &lt;i&gt;can&lt;/i&gt; get away with it; heck, just throw away all your rubbish and use an off-the-shelf solution if you hit a problem; but I&amp;#x27;m going to suggest that the majority of people aren&amp;#x27;t building that sort of platform, because its largely a solved problem.</text></item></parent_chain><comment><author>std_throwaway</author><text>I don&amp;#x27;t like opinionated pieces like the one presented here because while they are right about some things they miss other things and present half-truths as full-truths.&lt;p&gt;In my experience (and I have little of that) it&amp;#x27;s important to know the upgrade path and adjust your planning accordingly.&lt;p&gt;How many users can you serve with your solution?&lt;p&gt;How big do you expect the market to be in that stage?&lt;p&gt;What technology would be the next step?&lt;p&gt;How do you get there? How much more work would it be?&lt;p&gt;Always be one step ahead with technology, but not two. Most markets are surprisingly small. Most use cases scale surprisingly well. You can probably push your solution by an order of one magnitude if you need it quickly.&lt;p&gt;In order to answer the questions you need people who know the product, the (potential) technologies and the market. When you start you probably won&amp;#x27;t know any of that. See the first prototype you deploy to the customers as a means of collecting data for the first production version. Your first product is not your first product. Your funding should respect that. Get it done quickly with the aim of answering the critical questions. Then go back and design the next version &amp;quot;good-enough&amp;quot; for the second scaling step with the upgrade path in mind.</text></comment>
<story><title>Does it scale? Who cares (2011)</title><url>https://jacquesmattheij.com/does-it-scale-who-cares</url></story><parent_chain><item><author>shadowmint</author><text>I care.&lt;p&gt;It&amp;#x27;s easy to brush off scaling concerns as not important, but I&amp;#x27;ve had personal experience where it&amp;#x27;s mattered, and if you want a high profile example, look at twitter.&lt;p&gt;Yes, premature optimization is a bad thing, and so is over engineering; but that&amp;#x27;s easy to say &lt;i&gt;if&lt;/i&gt; you have the experience to make the right initial choices that mean you have a meaningful path forward &lt;i&gt;to scale&lt;/i&gt; when you do need it.&lt;p&gt;For example, lets say you build a typical business app and push something out quickly that doesn&amp;#x27;t say, log when it fails, or provide an auto-update mechanism, or have any remote access. Now you have it deployed at 50 locations and its &amp;#x27;not working&amp;#x27; for some reason. Not only do you physically have to go out to see whats wrong, you have to organize a reinstall at 50 locations. Bad right? yes. It&amp;#x27;s very bad. (&amp;lt;---- Personal experience)&lt;p&gt;Or, you do a similar ruby or python app when your domain is something that involves bulk processing massive loads of data. It works fine and you have a great &amp;#x27;platform&amp;#x27; until you have 3 users, and then it starts to slow down for everyone; and it turns out, you need a dedicated server for each customer because doing your business logic in a slow language works when you only need to do 10 items a second, not 10000. Bad right? yes. Very. Bad. (&amp;lt;---- Personal experience)&lt;p&gt;It&amp;#x27;s not premature optimization to not pick stupid technology choices for your domain, or ship prototypes.&lt;p&gt;...but sometimes you don&amp;#x27;t have someone on the team with the experience to realize that, and the push from management is to just get it out, and not worry about the details; but trust me, if you have someone who is sticking their neck out and go, hey wait, this isn&amp;#x27;t going to scale...&lt;p&gt;Maybe you should listen to what they have to say, not quote platitudes.&lt;p&gt;Ecommerce is probably one of those things where the domain is well enough known you &lt;i&gt;can&lt;/i&gt; get away with it; heck, just throw away all your rubbish and use an off-the-shelf solution if you hit a problem; but I&amp;#x27;m going to suggest that the majority of people aren&amp;#x27;t building that sort of platform, because its largely a solved problem.</text></item></parent_chain><comment><author>Trundle</author><text>The article is about choosing a business idea where technical scale isn&amp;#x27;t important. Twitter would fall under a &amp;quot;media play&amp;quot; which is what the author is telling the reader not to do. They aren&amp;#x27;t saying &amp;quot;try to build twitter but skimp on the tech&amp;quot; they&amp;#x27;re saying &amp;quot;don&amp;#x27;t try to build twitter, build something where people pay you money to use it and you&amp;#x27;ll be raking in millions in profit by the time technical scaling is an issue&amp;quot;. Terrible example imo.</text></comment>