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

131–140 of 554 posts

Re: Laws of Software Engineering

#131

Post by austin-cheney »

My own personal law is:

When it comes to frameworks (any framework) any jargon not explicitly pointing to numbers always eventually reduces down to some highly personalized interpretation of easy.

It is more impactful than it sounds because it implicitly points to the distinction of ultimate goal: the selfish developer or the product they are developing. It is also important to point out that before software frameworks were a thing the term framework just identifies a defined set of overlapping abstract business principles to achieve a desired state. Software frameworks, on the other hand, provide a library to determine a design convention rather than the desired operating state.

Re: Laws of Software Engineering

#132

Post by horsawlarway »

fineIllregister wrote: post #111
horsawlarway wrote: post #28

Earlier quoted context omitted.

At least for your last point... ideally never. Look, I understand the intent you have, and I also understand the frustration at the lack of care with which many companies have acted with regards to personal data. I get it, I'm also frustrated. But (it's a big but)... Your suggestion is that we hold people legally responsible and culpable for losing a confrontation against another motivated, capable, and malicious par…

We have HIPAA in the US for health care data. There have been no disastrous consequences to holding people and organizations responsible for breaches.

Sure, and in cases of negligence this is fine. The law even explicitly scales the punishment based on perceived negligence and almost always is only prosecuted in cases where the standards expectations aren't followed.

Ex - MMG for 2026 was prosecuted because:

- They failed to notify in response to a breach.

- They failed to complete proper risk analysis as required by HIPAA

They paid 10k in fines.

It wasn't just "They had a data breach" (ops proposal...) it was "They failed to follow standards which led to a data breach where they then acted negligently"

In the same way that we don't punish an architect if their building falls over. We punish them if the building falls over because they failed to follow expected standards.

Re: Laws of Software Engineering

#134

Post by mosburger »

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.

I said this elsewhere in the comments, but I think there's sort of a fundamental tension that shows up sometimes between DRY and "a function/class should only do one thing." E.g., there might be two places in your code that do almost identical things, so there's a temptation to say "I know! I'll make a common function, I'll just need to add a flag/extra argument..." and if you keep doing that you end up with messy "DRY" functions with tons of conditional logic that tries to do too much.

Yeah there are ways to avoid this and you need to strike balances, but sometimes you have to be careful and resist the temptation to DRY everything up 'cuz you might just make it brittler (pun intended).

Re: Laws of Software Engineering

#135

Post by horsawlarway »

jcgrillo wrote: post #127
horsawlarway wrote: post #118

Earlier quoted context omitted.

Define "safety".

Obviously if someone dies or is injured a safety violation has occurred. But other examples include things like data protection failures--if for example your system violates GDPR or similar constraints it is unsafe. If your system accidentally breaks tenancy constraints (sends one user's data to another user) it is unsafe. If your system allows a user to escalate privileges it is unsafe. These kinds of failures are n…

None of those are what OP proposed. Frankly, we also cover many of these practices just fine. What do you think SOC 2 type 2 and ISO 27001 are?

It seems like your issue is that we don't hold all companies to those standards. But I'm personally ok with that. In the same way I don't think residential homes should be following commercial construction standards.

Re: Laws of Software Engineering

#137

Post by ebonnafoux »

Edman274 wrote: post #122
ebonnafoux wrote: post #115

There is a small typos in The Ninety-Ninety Rule > The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%. It should be 90% code - 10% time / 10% code - 90% time

It sounds like you are unfamiliar with the idea that software engineering efforts can be underestimated at the outset. The humorous observation here is that the total is 180 percent, which mean that it took longer than expected, which is very common.

Oh OK, that is something I learn today.

Re: Laws of Software Engineering

#138

Post by GuB-42 »

> 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 today, performance is mostly about architectural choices, and it has to be given consideration right from the start. In 1974, these architectural choices weren't choices, the hardware didn't let you do it differently.

Focusing on the "critical 3%" (which imply profiling) is still good advice, but it will mostly help you fix "performance bugs", like an accidentally quadratic algorithms, stuff that is done in loop but doesn't need to be, etc... But once you have dealt with this problem, that's when you notice that you spend 90% of the time in abstractions and it is too late to change it now, so you add caching, parallelism, etc... making your code more complicated and still slower than if you thought about performance at the start.

Today, late optimization is just as bad as premature optimization, if not more so.

Re: Laws of Software Engineering

#139

Post by js8 »

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.

I thought that you were about to write: "as a janitor in a restaurant, the dessert topping is sometimes used as a floor polish".
Post reply on HN