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

501–510 of 554 posts

Re: Laws of Software Engineering

#501

Post by Shorel »

bartread wrote: post #405
Shorel wrote: post #317

Earlier quoted context omitted.

To me that's the people who write desktop software in Electron. Hate that.

I believe use of Electron is known as premature deoptimisation and if it had been a thing when Knuth coined the original phrase I'm sure he would have come up with that term too. Use of Electron to deliver software is popular and works but that doesn't make it any less of an abomination. I'm actually considering, for the first time since 2013/14 when I worked on a Visual Studio extension, creating a piece of desktop…

I am testing Slint for exactly the same thing. An alternative to Qt/wxWidgets.

It is written in Rust.

Re: Laws of Software Engineering

#502

Post by ai_fry_ur_brain »

deaux wrote: post #230

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 notewo…

If I think you vibe coded your website im not using your product, reading your blog and will bad mouth you at every opportunity.

Re: Laws of Software Engineering

#504

Post by zahlman »

onionisafruit wrote: post #155
zahlman wrote: post #79

Earlier quoted context omitted.

I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?

I’ll give a simplified example of something I have at work right now. The program moves data from the old system to the new system. It started out moving a couple of simple data types that were basically the same thing by different names. It was a great candidate for reusing a method. Then a third type was introduced that required a little extra processing in the middle. We updated the method with a flag to do that e…

> Then a third type was introduced that required a little extra processing in the middle. We updated the method with

A callback to do the processing?

> a flag

Oh.

> Now... several arguments... probably just a few lines that get run for all the types

Yeah, that does tend to be where it leads when new parameters are thought of in terms of requesting special treatment, rather than providing more tools.

Yes, yes, "the complexity has to go somewhere". But it doesn't all have to get heaped into the same pile, or mashed together with the common bits.

Re: Laws of Software Engineering

#507

Post by msla »

switchbak wrote: post #294
msla wrote: post #180

Earlier quoted context omitted.

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

"Why is this person testing that Arizona does such bizarre things with time? Surely no actual state is like that! Such complexity! Take it out!"

Re: Laws of Software Engineering

#508

Post by komi013 »

ai_fry_ur_brain wrote: post #502
deaux wrote: post #230

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 notewo…

If I think you vibe coded your website im not using your product, reading your blog and will bad mouth you at every opportunity.

user name checks out

Re: Laws of Software Engineering

#509

Post by ratherbefuddled »

boonzeet wrote: post #477
tombert wrote: post #335

Earlier quoted context omitted.

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…

Ironically to your point, I think adding a ConcurrentHashMap because it might be multithreaded eventually IS premature optimisation. The work can be done in future to migrate to using ConcurrentHashMap when the feature to add multithreading support is added. There's no sense to add groundwork for unplanned, unimplemented features - that is premature optimisation in a nutshell.

Typing ten extra characters is an investment that pays off vs the overhead of doing any piece of work in the future. There's no real downside here, it doesn't make the code more complex, it gives less surprising results.

I think you are conflating YAGNI and premature optimisation and neither apply in this case.

Re: Laws of Software Engineering

#510

Post by yodsanklai »

Many of these laws are trade-offs to be assessed on a case by case basis. Everybody has a different subjective view and you need to be willing to compromise otherwise you'll be very sad working with other people.
Post reply on HN