

Ask HN: Is it safe to (temporarily) ignore efficiency in your product? - jfasi

<i></i>tl;dr down below<i></i><p>As a university-trained, big-company-bred, C-was-my-first-language, I-think-about-data-structures-and-algorithm-in-the-shower engineer, I&#x27;ve always built everything I did with a very specific thought in the back of my head: &quot;Is this solution efficient?&quot;<p>However, as I&#x27;ve started getting more and more into developing web services in my spare time, I find myself struggling not with a mandate for speed, but rather with the sheer complexity of the system I&#x27;m trying to implement. Web applications are complicated beasts; there&#x27;s a lot going on that you need to fit in your head all at once, and thinking about efficiency only makes it worse.<p>Therefore I ask you: How much &quot;fuck it, I&#x27;ll use off-the-shelf components&quot; and &quot;fuck it, it&#x27;ll run in linear time&quot; can I get away with for the sake of pushing something out there? Does the quality of modern frameworks and hardware grant me a certain amount of slack for free?<p><i></i>tl;dr<i></i><p>I have never deployed or supported an entire user-facing web application. Can you please give me an idea of the sort of load you can handle with a typical application framework and a typical hardware deployment? Bonus points for numbers like requests per second or concurrent connections. I&#x27;d <i></i>really<i></i> love to know how many requests you serve with how many machines.<p>Edit: I anticipate the &quot;Why worry about performance when you don&#x27;t have users?&quot; response, and I thank you in advance. However, the last thing I want to happen is to <i>gain</i> users, only to discover that my potentially popular application is crippled by its being too slow and my being too busy to fix it.
======
orangethirty
As someone who mostly works with user facing web applications:

1\. You will always be playing catch up if your growth takes off. Not an
excuse to write your system in BASIC, but enough of a reason to forgo
efficiency _a little bit_. Shipping something that is 90% efficient is better
than not shipping something that is 100% efficient. I have lost almost one
year on the latter.

2\. The importance in a web application project (if you are aiming to use it
as a business) is your ability to adapt to what the market wants. If you
cannot push out features (inefficient ones), then somebody else who can will
swoop in.

3\. In terms of numbers: I have built systems that handle 10K/requests per
second without a sweat. Using standard boxes and Go. Note that as nice a Go
is, its still a young language. A typical python/ruby/php system can be made
to handle that, but requires a bit more work. Now, what I tell people is build
something _safe_ (as in no SQL injections, XSS, etc) first, then focus on
growing it. Picking a good stack early on helps, but don't pick a stack you
don't know. Someone who is proficient in PHP should not use Rails (example).

4\. The key to web services is to find and build things that people want. How
do you that? Pay attention to people on social networks.

If you have a background in C, Go and Python feel the most familiar. Some
prefer Ruby, which is another fine language. Be aware of the current trend of
everything being written in Javascript. Learn to use the language as you move
along. You will need it.

tl;dr

Don't think about _business-oriented_ web apps in terms of efficiency from the
start. Use what you know to build something secure and stable, and then if it
catches on, scale it.

Like PG said, _do things that don 't scale_.

