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

241–250 of 554 posts

Re: Laws of Software Engineering

#241

Post by CyberDildonics »

inetknght wrote: post #80
Aaargh20318 wrote: post #63

I’m missing Curly’s Law: https://blog.codinghorror.com/curlys-law-do-one-thing/ “A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance, and carry a different value from a different domain some other time. It should not mean two things at once. It must not be both a floor polish and a dessert topping. It should mean One Thing, and should mean it all of the time.”

> It must not be both a floor polish and a dessert topping. I worked as a janitor for four years near a restaurant, so I know a little bit about floor polishing and dessert toppings. This law might be a little less universal than you think. There are plenty of people who would happily try out floor polish as a dessert topping if they're told it'll get them high.

floor polish as a dessert topping if they're told it'll get them high.

I think that would be called a drug, not a desert topping.

Re: Laws of Software Engineering

#242

Post by zdc1 »

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?

Counterpoint: "everything in moderation, including moderation"

Re: Laws of Software Engineering

#243

Post by gavmor »

dzjkb wrote: post #176
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.

here's a nice critique of SOLID principles: https://www.tedinski.com/2019/04/02/solid-critique.html

This doesn't seem to be a critique of the principles so much as a critique of their phrasing.

Even his "critique" of Demeter is, essentially, that it focuses on an inconsequential aspect of dysfunction—method chaining—which I consider to be just one sme that leads to the larger principle which—and we, apparently, both agree on this—is interface design.

Re: Laws of Software Engineering

#245

Post by voiceofunreason »

RivieraKid wrote: post #27

Not a law but a a design principle that I've found to be one of the most useful ones and also unknown: Structure code so that in an ideal case, removing a functionality should be as simple as deleting a directory or file.

See also: https://programmingisterrible.com/post/139222674273/write-co...

Re: Laws of Software Engineering

#246

Post by mrkeen »

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

Negative.

The only part of SOLID that is perhaps OO-only is Liskov Substitution.

L is still a good idea, but without object-inheritance, there's less chance of shooting yourself in the foot.

Re: Laws of Software Engineering

#247

Post by dabedee »

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…

- The domain will be a long title with a dot com at the end.

Re: Laws of Software Engineering

#248

Post by f1shy »

segmondy wrote: post #210
newsoftheday wrote: post #207

Earlier quoted context omitted.

They start by indicating people don't understand, “A module should have only one reason to change.”. Reading more of that article, it's clear the author doesn't understand much about software engineering and sounds more like a researcher who just graduated from putting together 2+2.

The great thing bout the net is also it's biggest problem. Anyone can write a blog and if it looks nice, sounds polished they could sway a large group. I roll my eyes so strong at folks that reject SOLID principles and design patterns.

I have seen way too often, advocates of SOLID and patterns to have religious arguments: I don’t like it. That being said, I think there is nothing bad in SOLID, as long as treated as principles and not religious dogmas. About patterns, I cannot really say as much positive. They are not bad per-se. But I’ve seen they have made lots of harm. In the gang of 4 book, in the preface, I think, says something like “this list is neither exhaustive, nor complete, and often inadequate” the problem is every single person I know who was exposed to the book, try to hammer every problem into one pattern (in the sense of [1]). Also insist in using the name everywhere like “facade_blabla” IMHO the pattern may be Façade, but putting that through the names of all classes and methods, is not good design.

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Re: Laws of Software Engineering

#250

Post by voiceofunreason »

biscuits1 wrote: post #211

Today, I was presented with Claude's decision to include numerous goto statements in a new implementation. I thought deeply about their manual removal; years of software laws went against what I saw. But then, I realized it wouldn't matter anymore. Then I committed the code and let the second AI review it. It too had no problem with goto's. Claude's Law: The code that is written by the agent is the most correct way t…

Render therefore unto Caesar the things which are Caesar's; and unto Claude the things that are Claude's.
Post reply on HN