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

291–300 of 554 posts

Re: Laws of Software Engineering

#291

Post by switchbak »

WalterBright wrote: post #273
afpx wrote: post #254

Earlier quoted context omitted.

The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)

> 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, w…

It's substantially worse on the JVM. One's intuition from C just fails when you have to think about references vs primitives, and the overhead of those (with or without compressed OOPs).

I've met very few folks who understand the overheads involved, and how extreme the benefits can be from avoiding those.

Re: Laws of Software Engineering

#292

Post by CyberDildonics »

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…

Unfortunately people do keep repeating it to excuse the fact that they don't know how to optimize in the first place.

Anyone who has done optimization even a little knows that it isn't very difficult, but you do need to plan and architect for it so you don't have to restructure you whole program to get it to run well.

Mostly it's just rationalization, people don't know the skill so they pretend it's not worth doing and their users suffer for it.

If software and website were even reasonably optimized people could just use a computer as powerful as a rasberry pi 5 (except for high res video) for most of what they do day to day.

Re: Laws of Software Engineering

#293

Post by TheGRS »

You know, I mention this stuff all the time in various meetings and discussions. I read a lot of stuff on Hacker News and just have years of accumulated knowledge from the various colleagues I've worked with. Its nice to have a little reference sheet.

Re: Laws of Software Engineering

#294

Post by switchbak »

msla wrote: post #180
iamflimflam1 wrote: post #151

Earlier quoted context omitted.

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

> Similar to the "code should be self documenting - ergo: We don't write any comments, ever" My counterpoint: Code can be self-documenting, reality isn't. You can have a perfectly clear method that does something nobody will ever understand unless you have plenty of documentation about why that specific thing needs to be done, and why it can't be simpler. Like having special-casing for DST in Arizona, which no other…

Documenting it in a way that ensures it satisfies the example case would be preferred. You know, like with a test.

Re: Laws of Software Engineering

#295

Post by zaphar »

physicles wrote: post #272
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

I’m one of those that have thrown out Postel’s law entirely. Maybe the issue is that it never defines “strict”, “liberal”, and “accept”. But at least for public APIs, it never made sense to me. If I accidentally accept bad input and later want to fix that, I could break long-time API users and cause a lot of human suffering. If my input parsing is too strict, someone who wants more liberal parsing will complain, and…

I probably use a different interpretation of Postel's law. I try not "break" for anything I might receive, where break means "crash, silently corrupt data, so on". But that just means that I return an error to the sender usually. Is this what Postel meant? I have no idea.

Re: Laws of Software Engineering

#296

Post by skydhash »

dhosek wrote: post #203
skydhash wrote: post #142

Earlier quoted context omitted.

Now, I tend towards the C idiom of having few files and not a deep structure and away from the one class, one file of Java. Less files to rename when refactoring and less files to open trying to understand an implementation.

One advantage of more smaller files is that merge conflicts become less common. I would guess that at least half of the trivial merge conflicts I see are two unrelated commits which both add some header or other definition at the top of the file, but because both are inserted at line 17, git looks at it and says, “I give up.” This in itself might not be enough to justify this, but the fewer files will lead to more ch…

for the first point, such merge commits are so trivial to fix that it’s barely takes time.

You got a point for incremental compilation. But fewer files (done well) is not really a challenge as everything is self contained. It makes it easier to discern orthogonal features as the dependency graph is clearer. With multiple files you find often that similar things are assumed to be identical and used as such. Then it’s a big refactor when trying to split them, especially if they are foundational.

Re: Laws of Software Engineering

#297

Post by dorkitude »

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…

Found the overbuilder!

Re: Laws of Software Engineering

#298

Post by SAI_Peregrinus »

afpx wrote: post #254
f1shy wrote: post #229

Earlier quoted context omitted.

It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?” I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is.

The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)

How many bits are in an `int` in C? What do you mean "at least 16", that's ridiculous, nobody would write a language that leaves the number of bits in basic elementary types partially specified‽

Re: Laws of Software Engineering

#299

Post by TheGRS »

whattheheckheck wrote: post #44
busfahrer wrote: post #30

Earlier quoted context omitted.

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

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.
Post reply on HN