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

111–120 of 554 posts

Re: Laws of Software Engineering

#111

Post by fineIllregister »

horsawlarway wrote: post #28
Antibabelic wrote: post #21

Software engineering is voodoo masquerading as science. Most of these "laws" are just things some guys said and people thought "sounds sensible". When will we have "laws" that have been extensively tested experimentally in controlled conditions, or "laws" that will have you in jail for violating them? Like "you WILL be held responsible for compromised user data"?

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.

Re: Laws of Software Engineering

#113

Post by rapnie »

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.

Borax is an example of a substance that is simultaneously used for skin care, household cleaning, as soldiering flux, and ant killer. But I guess it is a constant with variable effects. Hard to be found in local shops anymore.

Re: Laws of Software Engineering

#115

Post by ebonnafoux »

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

Re: Laws of Software Engineering

#116

Post by horsawlarway »

Antibabelic wrote: post #41
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…

Incidents happen in the meat world too. Engineers follow established standards to prevent them to the best of their ability. If they don't, they are prosecuted. Nobody has ever suggested putting people in jail for Russia using magic to get access to your emails. However, in the real world, there is no magic. The other party "outmatches" you by exploiting typical flaws in software and hardware, or, far more often, in…

We already have similar legal measures in software for following standards. These match very directly to engineering standards in things like construction and architecture. These are clearly understood, ex SOC 2, PCI DSS, GDPR, CCPA, NIST standards, ISO 27001, FISMA... etc... Delve is an example (LITERALLY RIGHT NOW!) of these laws being applied.

What we don't do in engineering is hold the engineer responsible when Russia bombs the bridge.

What you're suggesting is that we hold the software engineer responsible when Russia bombs their software stack (or more realistically, just plants an engineer on the team and leaks security info, like NK has been doing).

Basically - I'm saying you're both wrong about lacking standards, and also suggesting a policy that punishes without regard for circumstance. I'm not saying you're wrong to be mad about general disregard for user data, but I'm saying your "simple and clear" solution is bad.

... something something... for every complex problem there is an answer that is clear, simple, and wrong.

France killed their generals for losing. It was terrible policy then and it's terrible policy now.

Re: Laws of Software Engineering

#117

Post by aworks »

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 worked for awhile as a janitor in a college dorm. Not an easy job but it definitely revealed a side of humanity I might not have otherwise seen. Especially the clean out after students left for the year.

Re: Laws of Software Engineering

#118

Post by horsawlarway »

jcgrillo wrote: post #108
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…

> any software company should be legally responsible for not being able to match the resources of a nation-state that might want to compromise their data No. Not the company, holding companies responsible doesn't do much. The engineer who signed off on the system needs to be held personally liable for its safety. If you're a licensed civil engineer and you sign off on a bridge that collapses, you're liable. That's ho…

Define "safety".

Re: Laws of Software Engineering

#119

Post by cogman10 »

Uhh, I knew I wasn't going to like this one when I read it.

> Premature Optimization (Knuth's Optimization Principle)

> Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved.

This example is the exact example I'd choose where people wrongly and almost obstinately apply the "premature optimization" principles.

I'm not saying that you should write a custom hash table whenever you need to search. However, I am saying that there's a 99% chance your language has an inbuilt and standard datastructure in it's standard library for doing hash table lookups.

The code to use that datastructure vs using an array is nearly identical and not the least bit hard to read or understand.

And the reason you should just do the optimization is because when I've had to fix performance problems, it's almost always been because people put in nested linear searches turning what could have been O(n) into O(n^3).

But further, when Knuth was talking about actual premature optimization, he was not talking about algorithmic complexity. In fact, that would have been exactly the sort of thing he wrapped into "good design".

When knuth wrote about not doing premature optimizations, he was living in an era where compilers were incredibly dumb. A premature optimization would be, for example, hand unrolling a loop to avoid a branch instruction. Or hand inlining functions to avoid method call overhead. That does make code more nasty and harder to deal with. That is to say, the specific optimizations knuth was talking about are the optimizations compilers today do by default.

I really hate that people have taken this to mean "Never consider algorithmic complexity". It's a big reason so much software is so slow and kludgy.

Re: Laws of Software Engineering

#120

Post by hliyan »

_dain_ wrote: post #10

I have a lot of issues with this one: https://lawsofsoftwareengineering.com/laws/premature-optimiz... It leaves out this part from Knuth: >The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreactio…

I absolutely cannot stand people who recite this quote but has no knowledge of the sentences that come before or after it: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Post reply on HN