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

Laws of Software Engineering

lawsofsoftwareengineering.com

Post reply on HN
Print view View original

391–400 of 554 posts

Re: Laws of Software Engineering

#391

Post by ElectricalUnion »

giancarlostoro wrote: post #319
austin-cheney wrote: post #146

Earlier quoted context omitted.

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its nece…

> except for those 10% of situations where you know in advance that crucial performance is absolutely necessary Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;)

Those days, what I see as "premature database optimization" is non-DBAs, without query plans, EXPLAINS and profiling, sprinkling lots of useless single column indexes that don't cover the actual columns used for joins and wheres, confusing the query planner and making the database MUCH slower and therefore more deadlock-prone instead.

Re: Laws of Software Engineering

#393

Post by ragnese »

throwaway173738 wrote: post #74
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

I look at Postel’s law more as advice on how to parse input. At some point you’re going to have to upgrade a client or a server to add a new field. If you’ve been strict, then you’ve created a big coordination problem, because the new field is a breaking change. But if you’re liberal, then your systems ignore components of the input that they don’t recognize. And that lets you avoid a fully coordinated update.

Yes, what Postel's Law is about. That's the whole point of contrasting it with Hyrum's Law, no?

Hyrum's Law is pointing out that sometimes the new field is a breaking change in the liberal scenario as well, because if you used to just ignore the field before and now you don't, your client that was including it before will see a change in behavior now. At least by being strict, (not accepting empty arrays, extra fields, empty strings, incorrect types that can be coerced, etc), you know that expanding the domain of valid inputs won't conflict with some unexpected-but-previously-papered-over stuff that current clients are sending.

Re: Laws of Software Engineering

#394

Post by [deleted] »

throwaway173738 wrote: post #74
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

I look at Postel’s law more as advice on how to parse input. At some point you’re going to have to upgrade a client or a server to add a new field. If you’ve been strict, then you’ve created a big coordination problem, because the new field is a breaking change. But if you’re liberal, then your systems ignore components of the input that they don’t recognize. And that lets you avoid a fully coordinated update.

[deleted]

Re: Laws of Software Engineering

#395

Post by OkayPhysicist »

asmodeuslucifer wrote: post #320

I learned about Dunbar’s number (~150) is the size of a community in which everyone knows each other’s identities and roles. In anthropology class. You can ask someone to write down the name of everyone they can think of, real or fictional, live or dead and most people will not make it to 250. Some individuals like professional gossip columnists or some politicians can remember as many as 1,000 people.

Dunbar's number is largely psuedoscience. Dunbar just took the group size of gorillas, scaled up to humans based on brain size, and then published, without bothering with silly little details like actually testing human group sizes.

Re: Laws of Software Engineering

#396

Post by D-Coder »

TheGRS wrote: post #299
whattheheckheck wrote: post #44

Earlier quoted context omitted.

Why 3? What is this baseball? Take the 5 Rings approach. The purpose of the blade is to cut down your opponent. The purpose of software is to provide value to the customer. It's the only thing that matters. You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment

One is one. Two is a coincidence. And three is a trend. That's my personal head canon.

"Once is happenstance. Twice is coincidence. The third time it's enemy action." — Auric Goldfinger

Re: Laws of Software Engineering

#397

Post by sas224dbm »

WalterBright wrote: post #279
afpx wrote: post #274

Earlier quoted context omitted.

That's a reasonable answer. But, I meant they seemed to have little understanding or interest. I don't interview much, and I'm probably a poor interviewer. But, I guess I was expecting some discussion.

I ran into some comp sci graduates in the early 80's who did not know what a "register" was. To be fair, though, I come up short on a lot of things comp sci graduates know. It's why Andrei Alexandrescu and I made a good team. I was the engineer, and he the scientist. The yin and the yang, so to speak.

Oooh, saw Andrei's name pop up and remember his books on C++ back in the day .. ran into a systems engineer a while ago that asked why during a tech review asked why some data size wasn't 1000 instead of 1024.. like err ??

Re: Laws of Software Engineering

#398

Post by hunterpayne »

tombert wrote: post #335
GuB-42 wrote: post #138

> Premature optimization is the root of all evil. There are few principle of software engineering that I hate more than this one, though SOLID is close. It is important to understand that it is from a 1974 paper, computing was very different back then, and so was the idea of optimization. Back then, optimizing meant writing assembly code and counting cycles. It is still done today in very specific applications, but t…

The biggest issue I have with premature optimization is stuff that really doesn't matter . For example, in Java I usually use ConcurrentHashMap, even in contexts that a regular HashMap might be ok. My reasoning for this is simple: I might want to use it in a multithreaded context eventually and the performance differences really aren't that much for most things; uncontested locks in Java are nearly free. I've gotten…

1) You don't need ConcurrentHashMap to make code thread-safe. That's the most extreme version that means that you need a thread-safe iterator too.

2) Locks are cheap

3) I seriously doubt that the difference between a Map and a ConcurrentHashMap is measurable in your app

Which means that both, the comments on your PRs are irrelevant and you are still going too far in your thread-safety. So you are both wrong.

What you are right about is to focus on network calls.

Re: Laws of Software Engineering

#400

Post by hunterpayne »

pydry wrote: post #283
Sammi wrote: post #149

Earlier quoted context omitted.

The problem is that that this term gets misused to say the opposite of what it was intended for. It's particularly the kind of people who like to say "hur hur don't prematurely optimize" that don't bother writing decent software to begin with and use the term as an excuse to write poor performing code. Instead of optimizing their code, these people end up making excuses so they can pessimize it instead.

In my career Ive seen about 1000 instances of somebody trying to optimize something prematurely. Usually those people also have a good old whinge about the premature optimization quote being wrong or misinterpreted and general attitudes to software efficiency. Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

"Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path."

That's because your boss will never in a 1000 years hire the type of dev who can do that. And even if you did, there will be team members who will fight those fixes tooth and nail. And yes, I have a very cynical view of some devs but they earned that through some of the pettiest behavior I have ever seen.

Post reply on HN