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

61–70 of 554 posts

Re: Laws of Software Engineering

#61

Post by wesselbindt »

Two of my main CAP theorem pet peeves happen on this page:

- Not realizing it's a very concrete theorem applicable in a very narrow theoretical situation, and that its value lies not in the statement itself but in the way of thinking that goes into the proof.

- Stating it as "pick any two". You cannot pick CA. Under the conditions of the CAP theorem it is immediately obvious that CA implies you have exactly one node. And guess what, then you have P too, because there's no way to partition a single node.

A much more usable statement (which is not a theorem but a rule of thumb) is: there is often a tradeoff between consistency and availability.

Re: Laws of Software Engineering

#62

Post by pydry »

layer8 wrote: post #32
pydry wrote: post #29

Earlier quoted context omitted.

DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when t…

DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.

Renaming it doesnt change the nature of the problem.

There should often be two points of truth because having one would increase the coupling cost more than the benefits that would be derived from deduplication.

Re: Laws of Software Engineering

#63

Post by Aaargh20318 »

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

Re: Laws of Software Engineering

#65

Post by ipnon »

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

I usually invoke this by naming with POSIWID.
Post reply on HN