Ask HN: Is it safe to (temporarily) ignore efficiency in your product?
As a university-trained, big-company-bred, C-was-my-first-language, I-think-about-data-structures-and-algorithm-in-the-shower engineer, I've always built everything I did with a very specific thought in the back of my head: "Is this solution efficient?"
However, as I'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'm trying to implement. Web applications are complicated beasts; there's a lot going on that you need to fit in your head all at once, and thinking about efficiency only makes it worse.
Therefore I ask you: How much "fuck it, I'll use off-the-shelf components" and "fuck it, it'll run in linear time" 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?
tl;dr
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'd really love to know how many requests you serve with how many machines.
Edit: I anticipate the "Why worry about performance when you don't have users?" response, and I thank you in advance. However, the last thing I want to happen is to gain users, only to discover that my potentially popular application is crippled by its being too slow and my being too busy to fix it.
1 comment
[ 3.6 ms ] story [ 14.3 ms ] thread1. 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.