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

491–500 of 554 posts

Re: Laws of Software Engineering

#491

Post by mrzhangbo »

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 agree. The main reason for slow development is excessive optimization and over-design.

Re: Laws of Software Engineering

#492

Post by nixon_why69 »

tombert wrote: post #416
hunterpayne wrote: post #398

Earlier quoted context omitted.

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…

Locks are cheap performance-wise (or at least they can be) but they’re easy to screw up and they can be difficult to performance test. ConcurrentHashMap has the advantage of hiding the locking from me and more importantly has the advantage of being correct, and it can still use the same Map interface so if it’s eventually used downstream somewhere stuff like `compute` will work and it will be thread safe without and…

As soon as you have a couple of those ConcurrentHashMaps in scope with relationships between their elements, your concurrency story is screwed unless you've really thought everything out. I'd encourage using just plain HashMap to signal that there's no thread safety so you know to rethink everything if/when it comes up.

Re: Laws of Software Engineering

#493

Post by zaphar »

kortex wrote: post #435
ragnese wrote: post #387

Earlier quoted context omitted.

I don't think that interpretation makes that much sense. Isn't it a bit too... obvious that you shouldn't just crash and/or corrupt data on invalid input? If the law were essentially "Don't crash or corrupt data on invalid input", it would seem to me that an even better law would be: "Don't crash or corrupt data." Surely there aren't too many situations where we'd want to avoid crashing because of bad input, but we'd…

I actually dont think it's that obvious at all (unless you are a senior engineer). It's like the classic joke: A QA engineer walks into a bar and orders a beer. She orders 2 beers. She orders 0 beers. She orders -1 beers. She orders a lizard. She orders a NULLPTR. She tries to leave without paying. Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drin…

Right even for senior engineers this can be hard to get right in practice. Parse, don't validate is certainly one approach to the problem. Choosing languages that force you to get it right is another.

Re: Laws of Software Engineering

#494

Post by pelasaco »

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 question is always, "When is it no longer premature?" Normally, it means the system is already in production, users are suffering, and maintaining and supporting it is a nightmare. Then we engineers say, "We have to spend N sprints on that to pay the technical debt."

Re: Laws of Software Engineering

#495

Post by red_admiral »

austin-cheney wrote: post #146
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 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…

Knuth certainly writes better than Dijkstra, even if he lost the "goto" argument in the end.

Re: Laws of Software Engineering

#496

Post by pelasaco »

austin-cheney wrote: post #146
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 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…

Computer scientist here. I love Donald Knuth, but he never maintained production systems :)

I’m being a bit provocative here, just to make two points:

a) Software development back in the day, especially when it comes to service, reach, security, etc., was completely different from today. Black Friday, millions of users, SLAs, 24-hour service... these didn’t exist back then.

b) Because of so many conditions — some mentioned in point (a) - prematurity ends when the code is live in production. End.

Re: Laws of Software Engineering

#497

Post by heresie-dabord »

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

> these "laws" contain so many internal contradictions

Also notice how many of the so-called _software laws_ are actually statements about human behaviour and people-problems.

Confirmation bias, Dunning-Kruger Effect, Sunk-Cost Fallacy, Ringlemann Effect, Price's Law, Putt's Law, Conway's Law, Brook's Law, Peter Principle, Hanlon's Razor, Amara's Law...

Of the 59 "laws", only a small number are guiding principles specifically about planning and software.

Human behaviour is hard to change -- the same dysfunction can be seen everywhere. As a fundamental principle, you need to use the right/best tool for the job; you will know when you are using the wrong tool/solution because you'll spend a significant amount of time trying to correct/mask the unwanted consequences.

And if you enter a shop where many tools are wrong... consider going to work in a different shop.

Re: Laws of Software Engineering

#499

Post by g051051 »

> When I first started, I was enamored with technology and programming and computer science. I’m over it.

Wow, that is incredibly sad to hear. I'm 40+ years in, and still love all of that.

Re: Laws of Software Engineering

#500

Post by sltr »

hatsix wrote: post #224

I know it's not software-engineering-only, but Chesterton's Fence is often the first 'law' I teach interns and new hires: https://fs.blog/chestertons-fence/

the corollary of Chesterton's Fence is also valuable: don't go putting up unnecessary fences, because others won't be able to take them down
Post reply on HN