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

221–230 of 554 posts

Re: Laws of Software Engineering

#221

Post by cstoner »

tananaev wrote: post #143
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…

With modern tools it should be pretty easy to build scalable solutions. I take premature optimization as going out of your way to optimize something that's already reasonable. Not that you should write really bad code as a starting point.

Yeah, I interpret "premature optimization" as taking a request that takes 500ms and focusing on saving a couple ms by refactoring logic to avoid a SQL JOIN or something.

Your users are not going to notice. Sure, it's faster but it's not focused on the problem.

Re: Laws of Software Engineering

#222

Post by p0nce »

iamflimflam1 wrote: post #151
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…

> 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"

Laziness in moral clothing.

Re: Laws of Software Engineering

#223

Post by pcblues »

In the 25 odd years I developed software, I learnt all the rules the hard way.

Relax. You will make all the mistakes because the laws don't make sense until you trip over them :)

Comment your code? Yep. Helped me ten years later working on the same codebase.

You can't read a book about best practises and then apply them as if wisdom is something you can be told :)

It is like telling kids, "If you do this you will hurt yourself" YMMV but it won't :)

Re: Laws of Software Engineering

#225

Post by ozim »

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…

Sounds like we agree.

Bunch of stuff is done for us. Using postgres having indexes correct - is not premature optimization, just basic stuff to be covered.

Having double loop is quadratic though. Parallelism is super fun because it actually might make everything slower instead of faster.

Re: Laws of Software Engineering

#226

Post by cstoner »

enraged_camel wrote: post #160
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…

>> Today, late optimization is just as bad as premature optimization, if not more so. You are right about the origin of and the circumstances surrounding the quote, but I disagree with the conclusion you've drawn. I've seen engineers waste days, even weeks, reaching for microservices before product-market fit is even found, adding caching layers without measuring and validating bottlenecks, adding sharding pre-emptiv…

Thank your for posting this. I disagreed with OP but couldn't _quite_ find the words to describe why. But your post covers what i was trying to say.

I was quite literally asked to implement an in-memory cache to avoid a "full table scan" caused by a join to a small DB table recently. Our architect saw "full table scans" in our database stats and assumed that must mean a performance problem. I feel like he thought he was making a data-driven profiling decision, but seemed to misunderstand that a full-table scan is faster for a small table than a lookup. That whole table is in RAM in the DB already.

So now we have a complex Redis PubSub cache invalidation strategy to save maybe a ms or two.

I would believe that we have performance problems in this chunk of code, and it's possible an in-memory cache may "fix" the issue, but if it does, then the root of the problem was more likely an N+1 query (that an in-memory cache bandaids over). But by focusing on this cache, suddenly we have a much more complex chunk of code that needs to be maintained than if we had just tracked down the N+1 query and fixed _that_

Re: Laws of Software Engineering

#227

Post by pcblues »

xnx wrote: post #165
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…

> making your code more complicated and still slower than if you thought about performance at the start. Not if your optimization for performance is some Rube Goldberg assemblage of microservices and an laundry list of AWS services.

I still don't understand microservices for anything short of a NAG of four level architecture.

Re: Laws of Software Engineering

#228

Post by Exoristos »

someguyiguess wrote: post #171
ghosty141 wrote: post #167

Earlier quoted context omitted.

What's the problem with SOLID? It's very very rare that I see a case where going against SOLID leads to better design.

It only applies to the object oriented programming paradigm

This is only superficially true. Here's a fair discussion that could serve as a counterpoint: https://medium.com/@ignatovich.dm/applying-solid-principles-...

Re: Laws of Software Engineering

#229

Post by f1shy »

iamflimflam1 wrote: post #151
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…

> 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"

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.

Re: Laws of Software Engineering

#230

Post by deaux »

Laws of Software Engineering (2026 Update)

- Every website will be vibecoded using Claude Opus

This will result in the following:

- The background color will be a shade of cream, to properly represent Anthropic

- There will be excessive use of different fonts and weights on the same page, as if a freshman design student who just learned about typography

- There will be an excess of cards in different styles, a noteworthy amount of which has a colored, round border either on hover or by default on exactly one side of the card

Post reply on HN