Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Designing Your Web Application for Millions of Users When You Dont Have 100

darrenhorrocks.co.uk

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#81

Post by JohnBooty »

zimpenfish wrote: post #58
meribold wrote: post #48

Earlier quoted context omitted.

> I had to have a multi-day argument over the precise way to define constants in Perl Couldn't you have used whatever the other person was suggesting even if the change was pointless?

These days, I would, yeah, but this was a long time ago and I was a lot more invested in not letting nonsense go past without a fight.

Yeah it's one of those things where it's like...

...okay, I can let this nonsense go today with very little impact, but if I do... will the team need to deal with it 100 times in the future? (And more broadly, by silence am I contributing to the evolution of a bad engineering culture ruled by poor understandings?)

It is very very difficult to know where to draw the line.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#82

Post by KronisLV »

anal_reactor wrote: post #65
zimpenfish wrote: post #4

At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…

I'm stunned to realize that most developers just blindly follow whatever are the newest hottest "good practices" and completely ignore the actual goals that code should try to achieve. Literally yesterday I had an argument with a coworker because he wouldn't buy the argument "High-availability costs us $2000 per year extra, downtime costs us $100 per day, so if the database breaks once per year, there's no point havi…

> I gave up trying to reason with coworkers because it's just pain and changes nothing in the long run besides exhausting me.

What are you even supposed to do in such situations?

It might be not possible to make them see things your way or vice versa.

You probably don’t want to get the person fired and going to look for a new place of employment just because of one or two difficult people doesn’t seem all that nice either.

You can get the management on your side (sometimes), but even then that won’t really change anything about similar future situations.

To me, it seems like there aren’t that many options, whenever it’s anything more abstract than being able to point to a sheet of test results and say “A is better than B, we are doing A”.

I’ve had fundamental disagreements with other people as well, nowadays I don’t really try to convince them of anything and try to limit how deep those discussions get because often they’re quite pointless, whenever they’re not purely data based. That doesn’t actually fix anything and the codebases do get less pleasant to work with at times for someone like me.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#83

Post by anal_reactor »

mewpmewp2 wrote: post #75
anal_reactor wrote: post #65

Earlier quoted context omitted.

I'm stunned to realize that most developers just blindly follow whatever are the newest hottest "good practices" and completely ignore the actual goals that code should try to achieve. Literally yesterday I had an argument with a coworker because he wouldn't buy the argument "High-availability costs us $2000 per year extra, downtime costs us $100 per day, so if the database breaks once per year, there's no point havi…

On the other side of the argument, does $2000 a year seem a lot for high-availability? Does downtime really cost only $100 per day? How was it calculated? How much does your business make? It would seem it should make more than 365 * $100 = $36,500 to be able to be in a position to hire people in the first place. Database downtime would potentially: 1) Break trust with customers. 2) Take away focus from your engs for…

The whole thing is a side project with 5 customers total. If it dies it'll take a while before anyone notices.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#84

Post by mewpmewp2 »

anal_reactor wrote: post #83
mewpmewp2 wrote: post #75

Earlier quoted context omitted.

On the other side of the argument, does $2000 a year seem a lot for high-availability? Does downtime really cost only $100 per day? How was it calculated? How much does your business make? It would seem it should make more than 365 * $100 = $36,500 to be able to be in a position to hire people in the first place. Database downtime would potentially: 1) Break trust with customers. 2) Take away focus from your engs for…

The whole thing is a side project with 5 customers total. If it dies it'll take a while before anyone notices.

It's a side project but you are calling them coworkers and a company with company's goals?

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#85

Post by passion__desire »

n_ary wrote: post #77

Counter argument is that, you do not know whether your system will go big next week. If it indeed does, now you do not have the Google/Meta/Amazon engineer legion to immediately scale it up without losing users[1]. Also, a gambit of scalable system initially helps to solve the later death-march, when management wants to ship the MVP in global production and then come howling when users are bouncing because the system…

The other point is what if your Company's exit strategy is dependent on going big. Then it is pertinent that you plan for that 0.01% chance because there is no other exit.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#86

Post by cultofmetatron »

michaelteter wrote: post #40

Yes but... Still make some effort to build as if this were a professional endeavor; use that proof of concept code to test ideas, but rewrite following reasonable code quality and architecture practices so you don't go into production with lack of ability to make those important scaling changes (for if/when you get lucky and get a lot of attention). If your code is tightly coupled, functions are 50+ lines long, objec…

> There are two languages that start with "P" which seem to often end up in production like this.

I think thats more due to their tendency to be grabbed by n00bs than any deficiencies in said languages.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#87

Post by mewpmewp2 »

JohnBooty wrote: post #80
zimpenfish wrote: post #4

At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…

Ugggggggggggh. My favorite part of the job is scaling/optimization, and my least favorite part of the job is... this. There are a LOT of "engineers" who understand that one thing might be faster than another thing, but lack the chops/wisdom to understand when it actually matters.

Best example I've seen is wanting to optimize a frontend JS for loop that gets triggered maximally only once per page load, runs max 100 times in a loop with complicated data structures that will confuse any reader of that code why it was done like this and not just with a for loop.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#88

Post by mewpmewp2 »

n_ary wrote: post #77

Counter argument is that, you do not know whether your system will go big next week. If it indeed does, now you do not have the Google/Meta/Amazon engineer legion to immediately scale it up without losing users[1]. Also, a gambit of scalable system initially helps to solve the later death-march, when management wants to ship the MVP in global production and then come howling when users are bouncing because the system…

Counter point - even if you spend more time on scale and system setup you will still be prone to failure without having this scale tested and stepped up progressively.

And I think ironically you are more likely to get higher scale if you spend less time on scaling, since you spend more time building other things that users care about.

And frequently if focusing on scale, you will run into bugs that you wouldn't if you would just use a simple one box monolith. Your incident resolving might take longer with a scalable microservices arch because debugging and everything becomes much more complex.

You have limited resources where you are assigning skill points to your character. But the thing is, if you do a more complex arch, it will keep taking away those skill points not only in the beginning but over time.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#89

Post by JohnBooty »

mewpmewp2 wrote: post #87
JohnBooty wrote: post #80

Earlier quoted context omitted.

Ugggggggggggh. My favorite part of the job is scaling/optimization, and my least favorite part of the job is... this. There are a LOT of "engineers" who understand that one thing might be faster than another thing, but lack the chops/wisdom to understand when it actually matters.

Best example I've seen is wanting to optimize a frontend JS for loop that gets triggered maximally only once per page load, runs max 100 times in a loop with complicated data structures that will confuse any reader of that code why it was done like this and not just with a for loop.

It's such a Dunning-Kruger effect. You get legitimately talented engineers who are talented enough to do a legitimately hard thing: optimizing a complex piece of code.

So, they don't realize that there's kind of another level of understanding beyond that (when to optimize vs. how to optimize)

There's also the fact that some people just like optimizing shit for selfish or even slightly nefarious reasons. Some just like doing it because it's fun. Others like it because it gives them visible and easily quantified "wins." On the rarer and more nefarious side of things, they may enjoy now having "ownership" over a piece of complex code that only they can understand....

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#90

Post by emmanueloga_ »

Focusing on customers and MVPs over complex architecture makes sense, but whether you have 10 or 1 million users, for any real business, you need to be ready to recover from outages.

Building for resilience early sets the foundation for scaling later. That’s why I’m not a fan of relying on "one big server." No matter how powerful, it can still fail.

By focusing on resilience, you're naturally one step closer to scaling across multiple servers. Sure, it’s easy to overcomplicate things, but investing in scalable infrastructure from the start has benefits, even with low traffic—it's all about finding the right balance.

Post reply on HN