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

Squeeze the hell out of the system you have

blog.danslimmon.com

Post reply on HN
Print view View original

221–230 of 383 posts

Re: Squeeze the hell out of the system you have

#221

Post by eru »

killjoywashere wrote: post #108
KnobbleMcKnees wrote: post #56

Earlier quoted context omitted.

That was Donald Rumsfeld!? I always assumed this came from some techie or agile guru given how much it's used as a concept in project planning.

As a military officer who was watching CNN live from inside an aircraft carrier (moored) when he said that, being in charge of anti-terrorism on the ship at the time, it was absolutely foundational to my approach to so many things after that. Here's the actual footage: https://www.youtube.com/watch?v=REWeBzGuzCc Rumsfeld was complicated, but there's no doubt he was very effective at leading the Department. I think mo…

> [...] the Internet lets people indulge in a Dunning-Kruger situation the likes of which humanity has never seen.

While we are at it, that infamous Dunning-Kruger study showed didn't even claim what people like to pretend it claimed. In addition the more nuanced claim they did make is not supported by the evidence they collected and presented in their paper. (Their statistics are pretty much useless, and as with any social science study, it has a small 'n' and it doesn't replicate.)

But the mythology 'Dunning-Kruger effect' is too good to pass up in Internet discussions, so it survives as a meme.

Re: Squeeze the hell out of the system you have

#222

Post by latchkey »

jodrellblank wrote: post #180
latchkey wrote: post #38

Earlier quoted context omitted.

All in all though, I don't think that 'never use joins' is a good solution either since it does create more developer work almost every way you slice it. I think the op's solution of looking more closely at the hot paths and solving for those is a far better solution than re-architecting the application in ways that could, or can, create unintended consequences. People don't consider that enough, at all. Don't forget…

Grab was the company Steve Yegge left Google to go to. He quit during COVID when he could no longer travel to Asia, and his retrospective is glowing, including of the CTO Mark Porter(I think?): " frankly, the “Grab Way” of collaboration teaches you life skills, such as psychological safety and inclusiveness, which work everywhere else as well. [...] We US Grabbers made many mistakes on the journey towards becoming be…

Sorry, I gave the wrong role, it was this guy... VP of Eng [0] that fired me and then left for 'personal reasons'... he was fired. Classic incompetent VP Eng manager who didn't know anything about computers. Note how he never really found another position of equal stature as Grab...

I came along as an aquihire of a Vietnamese team that I just happened to be managing at the time. Great team of people. I negotiated a stupid high salary, probably because they weren't used to someone negotiating at all (highest eng in all of Singapore) and that was part of why they were upset at me, I was making more than that VP of Eng and stirring the pot with comments about their poor architecture decisions.

Yegge was a good hire, but probably wrong company for him given the political differences. I think Yegge started a bit after I was fired. I remember thinking to myself that he's either not going to be very effective or he won't last long. To his credit, I think he lasted longer than I would have bet he would have. They had had another ex FB CTO much earlier before me, that was a train wreck [1] and ended up suing the company. They were without a CTO for a long time, probably thought Yegge could fill that roll and ended up hiring Mark instead.

There was a definite distinction between the Singapore and US/Seattle teams, at least the short time while I was there, they pretty much didn't talk to or like each other at all. It made getting those API calls almost impossible.

[0] https://www.techinasia.com/kumaravel-leaves-grab

[1] https://www.techinasia.com/wei-zhu-leaves-grabtaxi

Re: Squeeze the hell out of the system you have

#223

Post by eru »

prmph wrote: post #145
sainez wrote: post #59

Earlier quoted context omitted.

Great point about working on teams. For the vast majority of tasks, people are only marginally better or worse than each other. A few people with decent communication will outpace a "star" any day of the week. I try to remind myself of this fact when I'm frustrated with other people. A bit of humility and gratitude go a long way.

Hmmmm, I really don't think this is true all (or even most of) the time. It probably depends on the task at hand, but if leading small teams of all kinds has taught me anything, it's that I'd prefer a tiny team (or even one person) who is at least above average competence, and is reflective of the work they are doing, than several people of average or below-average competence. It's eye opening how many people are out…

Btw, excellent communication can also be the skill that makes a 'star'.

Re: Squeeze the hell out of the system you have

#224

Post by eru »

macNchz wrote: post #121

In my experience, in web apps built on top of ORMs there is often a TON of low hanging fruit for query optimization when database load becomes an issue. Beyond the basics of "do we have N+1 issues", ORMs sometimes just don't generate optimal queries. I wouldn't want to built a complex production web app without an ORM, but being able to eject from it sometimes is key. Profile real world queries being run in productio…

A big problem with ORM's is that object orientation is just not a good way to organise software nor data for most domains.

Most business logic would be better expressed in the language of relational algebra (plus some extensions) than via OOP.

Re: Squeeze the hell out of the system you have

#225

Post by dragonwriter »

froggit wrote: post #194
dragonwriter wrote: post #101

Earlier quoted context omitted.

> Rumsfeld's got some great quotes, most of which were delivered in the context of explaining how the Iraq war turned into such a clusterfuck If by “explaining how” you mean “deflecting (often preemptively) responsibility for”, yes.

> If by “explaining how” you mean “deflecting (often preemptively) responsibility for”, yes. There's no reason to think you can't do both of those with the same statement.

Abstractly, sure.

I’m characterizing what I recall Rumsfeld concretely doing, not what is abstractly possible for one to do.

Re: Squeeze the hell out of the system you have

#226

Post by lll-o-lll »

feoren wrote: post #144
pipe_connector wrote: post #135

Earlier quoted context omitted.

I agree with the characterization of applications you've laid out and think everyone should consider whether they're working on a "tall" (most users use a narrow band of functionality) or a "wide" (most users use a mostly non-overlapping band of functionality) application. I also agree with your take that tall applications are generally easier to build engineering-wise. Where I disagree is that I think in general wid…

> I've worked on a ton of wide applications, and each of them eventually became loathed by users and really hard to design features for. Yes, I agree that this is the fate of most. But I refuse to believe it's inevitable; rather, I think it comes from systemic flaws in our design thinking. Most of what we learn in a college database course, most of what we read online, most all ideas in this space, transfer poorly to…

> Yes, I agree that this is the fate of most. But I refuse to believe it's inevitable

Yes exactly. It is not inevitable, I’ve worked on several “enterprise” software suits that did not suffer from this problem. However! They all had that period in their history where they did, and this is why:

Early on in a companies history there will be a number of “big” customers from whom most of the revenue is coming. To keep those customers and money flowing, often bespoke features are added for these customers and these accumulate over time. This is equivalent in character to maintaining several forks of an OSS project. Long term no forward progress can be made due to all time ending up in maintenance.

The solution to this sorry state is to transition to an “all features must be general for the product” and ruthlessly enforce this. That will also mean freezing customer specific “branches” and there will be a temporary hit to revenue. Customers need to be conditioned to the “no bespoke features” and they need to be sold on the long term benefits and be brought along for the ride.

This then enables massive scaling benefits, and the end of all your time in maintenance.

Re: Squeeze the hell out of the system you have

#227

Post by wvenable »

taylodl wrote: post #66
endisneigh wrote: post #6

The bit on the database performance issues leads me to my hottest, flamiest take for new projects: - Design your application's hot path to never use joins. Storage is cheap, denormalize everything and update it all in a transaction. It's truly amazing how much faster everything is when you eliminate joins. For your ad-hoc queries you can replicate to another database for analytical purposes. On this note, I have mixe…

My hot take: always use a materialized view or a stored procedure. Hide the actual, physical tables from the Application's account! The application doesn't need to know how the data is physically stored in the database. They specify the logical view they need of the data. The DBAs create the materialized view/stored procedure that's needed to implement that logical view. Since the application is never directly access…

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

> The application doesn't need to know how the data is physically stored in the database.

In all the applications that I've designed, the application and the database design are in sync. That's not say that you wouldn't use materialized views to deal with certain broad queries but I just don't see how this level of abstraction would make a big difference.

Re: Squeeze the hell out of the system you have

#228

Post by coldtea »

i_like_apis wrote: post #34

I’m reminded of one of my favorite sayings: You go to war with the army you have, not the army you might want or wish to have at a later time. You may want to ignore that this this comes from Donald Rumsfeld (he has some great ones though: “unknown unknowns …”, etc.) I think about this a lot when working on teams. Everyone is not perfectly agreeable or has the same understanding or collective goals. Some may be subop…

This however is a retelling of centuries old proverbs and quotes (all the way to Roosevel's "do what you can, with what you have, where you are"), and "unknown unknowns" was a concept already familiar in epistemology, but also fields like systems theory, risk management, etc.

Re: Squeeze the hell out of the system you have

#229

Post by coldtea »

hluska wrote: post #110
roughly wrote: post #72

Earlier quoted context omitted.

Rumsfeld's got some great quotes, most of which were delivered in the context of explaining how the Iraq war turned into such a clusterfuck, and boy could that whole situation have used the kind of leadership Donald Rumsfeld's quotes would lead you to believe the man could've provided.

I like to remind myself that very few people reach positions of great power after mediocre lives. Rather there’s a thread of talent that runs through government. Once they’re in, the predilections that led to power often rear their dark long tails. But they’re all (even the ones I disagree with) talented.

>I like to remind myself that very few people reach positions of great power after mediocre lives.

You'd be surprised.

"Reaching positions of great power after mediocre lives" is the very art of career politics.

Re: Squeeze the hell out of the system you have

#230

Post by meepmorp »

eru wrote: post #206
earthboundkid wrote: post #193

Earlier quoted context omitted.

As history, this is completely incorrect, but beyond that, if you don’t believe in the mission of the President in committing an act of war, you have a responsibility to resign, and it can’t be bracketed as “bad ethics”. Anyway, another historical point besides what the other commenters have said is that Rumsfeld believed in “transformation” which meant you could do more with less in modern war. He was totally wrong…

Funny enough, if you go by what's written in the US constitution, their president can't actually go to war. But thanks to enough loop holes, they can get into 'special military operations' (to misappropriate a recent term).

At no point in US history was it ever the case that every military operation was considered a war, nor that a war declaration would be necessary and/or appropriate to conduct such operations. What's more, Congress has frequently and explicitly given the President authority to conduct large scale military operations and held oversight hearings, etc. of the execution of those operations - all without formal declarations of war; Vietnam, Iraq, and Afghanistan being prime examples of this.

Calling them "special military operations," poor taste aside, especially with a focus on the formal process used, ignores the fact that all of those conflicts were entered and conducted with the full knowledge and involvement of Congresss.

Post reply on HN