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

331–340 of 554 posts

Re: Laws of Software Engineering

#331

Post by bluGill »

SAI_Peregrinus wrote: post #298
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.)

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‽

It is a good idea - most of the time you don't care, and on slower systems a large int is harmful since the system can't handle that much and it cost performance - go to the faster system with larger ints when you need larger intw.

Re: Laws of Software Engineering

#332

Post by Shorel »

toast0 wrote: post #259
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…

I only use mature optimizations, so I'm good. Thinking about the overall design, how its likely to be used, and what the performane and other requirements are before aggregating the frameworks of the day is mature optimization. Then you build things in a reasonable way and see if you need to do more for performance. It's fun to do more, but most of the time, building things with a thought about performance gets you w…

That first sentence.

I want it in a t-shirt. On billboards. Everywhere :)

Re: Laws of Software Engineering

#333

Post by dartharva »

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…

Strange, this is actually one of the most important things I learnt the hard way as an analyst having had the misfortune of being forced to do local-level data engineering after being tasked with doing extensive BI on heavy data volumes (I don't have engineering education) without cloud ETL. Had someone told me this simple statement before time it would have saved me a LOT of pain and effort.

Re: Laws of Software Engineering

#334

Post by cogman10 »

krust wrote: post #290
cogman10 wrote: post #119

Uhh, I knew I wasn't going to like this one when I read it. > Premature Optimization (Knuth's Optimization Principle) > Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved. This example is the exact example I'd choose where people wrong…

> Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved. To be fair, a linear search through an array is, most of the time, faster than a hash table for sufficiently small data sizes.

I'd say that this is premature optimization.

It doesn't take long for hash or tree lookups to start outperforming linear search and, for small datasets, it's not frequently the case that the search itself is a performance bottleneck.

Re: Laws of Software Engineering

#335

Post by tombert »

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 pull requests rejected because regular HashMaps are "faster", and then the comments on the PR ends up with people bickering about when to use it.

In that case, does it actually matter? Even if HashMap is technically "faster", it's not much faster, and maybe instead we should focus on the thing that's likely to actually make a noticeable difference like the forty extra separate blocking calls to PostgreSQL or web requests?

So that's the premature optimization that I think is evil. I think it's perfectly fine at the algorithm level to optimize early.

Re: Laws of Software Engineering

#336

Post by bluGill »

tombert wrote: post #322
NikolaosC wrote: post #201

Earlier quoted context omitted.

Spent 6 months last year ripping out an abstraction layer that made every request 40ms slower. We profiled, found the hot path, couldn't fix it without a rewrite. The "optimize later" school never tells you later sometimes means never

I'd say it usually means "never". I also find it a bit annoying is that most people just make shit up about stuff that is "faster". Instead of measuring and/or looking at the compiled bytecode/assembly, people just repeat tribal knowledge about stuff that is "faster" with no justification. I find that this is common amongst senior-level people at BigCos especially. When I was working in .NET land, someone kept tellin…

I've seen a lot of requests to obtimize code where we can measure the optimal versions saves a few nanoseconds. I just deleted some 'optimal code' that took a lot of mutexes and so was only faster when there is no contetion but in real world multi-writer situations the easy code wins. (Shared memory vs local socket for ipc)

Re: Laws of Software Engineering

#337

Post by AtNightWeCode »

regular_trash wrote: post #287

Hot take - I hate YAGNI. My personal pet peeve is when someone says YAGNI to a structure in the code they perceive as "more complex than they would have done it". Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on. Worst case…

It is misused if anything. YAGNI is about functionality. What to add or not. But it has become an excuse for being lazy. Same people that interpreted the line “Working software over comprehensive documentation” as no need for documentation.

Re: Laws of Software Engineering

#338

Post by alok-g »

jolt42 wrote: post #204
conartist6 wrote: post #13

Remember that these "laws" contain so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. The hard part is knowing which law break when, and why

I'll propose this as the only unbreakable law: "everything in moderation", which I feel implies any law is breakable, which now this is sounding like the barber's paradox. What else does anyone propose as unbreakable?

>> everything in moderation

Saying this is like saying 'pick the optimum point' without saying anything about how to find the optimum point. This cannot be a law, it is the definition of optimum.

Note that optimum point need not be somewhere in the middle or 'inside', like a maxima. The optimum point could very well be on an extreme of the domain (input variables space).

Re: Laws of Software Engineering

#339

Post by tombert »

bluGill wrote: post #336
tombert wrote: post #322

Earlier quoted context omitted.

I'd say it usually means "never". I also find it a bit annoying is that most people just make shit up about stuff that is "faster". Instead of measuring and/or looking at the compiled bytecode/assembly, people just repeat tribal knowledge about stuff that is "faster" with no justification. I find that this is common amongst senior-level people at BigCos especially. When I was working in .NET land, someone kept tellin…

I've seen a lot of requests to obtimize code where we can measure the optimal versions saves a few nanoseconds. I just deleted some 'optimal code' that took a lot of mutexes and so was only faster when there is no contetion but in real world multi-writer situations the easy code wins. (Shared memory vs local socket for ipc)

I don't write a lot of super low level stuff, so maybe things are different there, but at least in the normal user space level I've found it pretty rare that explicit mutexes ever beat the performance of an (in my opinion) easier design using queues and/or something like ZeroMQ.

Generally I've found that the penalty, even without contention, is pretty minimal, and it almost always wins under contention.

Re: Laws of Software Engineering

#340

Post by Sharlin »

alexjplant wrote: post #313
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"

> "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary beca…

You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance"
Post reply on HN