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

301–310 of 554 posts

Re: Laws of Software Engineering

#301

Post by datadrivenangel »

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…

It's important to occasionally execute or imprison a general to motivate the remaining generals. Rarely though.

Re: Laws of Software Engineering

#302

Post by zffr »

physicles wrote: post #272
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

I’m one of those that have thrown out Postel’s law entirely. Maybe the issue is that it never defines “strict”, “liberal”, and “accept”. But at least for public APIs, it never made sense to me. If I accidentally accept bad input and later want to fix that, I could break long-time API users and cause a lot of human suffering. If my input parsing is too strict, someone who wants more liberal parsing will complain, and…

One example where I think the law does make sense is for website URL paths.

Over time the paths may change, and this can break existing links. IMO websites should continue to accept old paths and redirect to the new equivalents. Eventually the redirects can be removed when their usage drops low enough.

Re: Laws of Software Engineering

#303

Post by blauditore »

Many of the "teams" laws are BS, especially the ones about promotions and management. I've never been a manager or high-level executive, but it's not that all of them are either non-technical or bad managers. It's just that the combination of both skills is rare.

Re: Laws of Software Engineering

#304

Post by estimator7292 »

afpx wrote: post #254
f1shy wrote: post #229

Earlier quoted context omitted.

It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?” I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is.

The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)

On the one hand, in today's world asking how many bits is in an int is exactly as answerable as "how long is a piece of rope"

On the other, the right answer is 16 or 32. It's not the correct answer, strictly speaking, but it is the right one.

Re: Laws of Software Engineering

#305

Post by randusername »

hliyan wrote: post #120
_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%."

Don't forget:

- The customer is always right in matters of taste

- Jack of all trades, master of none, but oftentimes better than a master of one

- Curiosity killed the cat, but satisfaction brought it back

- A few bad apples spoil the barrel

- Great minds think alike, though fools seldom differ

Even "pull yourself up by your bootstraps" was originally meant to highlight the absurd futility of a situation.

Re: Laws of Software Engineering

#306

Post by vanguardanon »

GuB-42 wrote: post #138

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

Is this less relevant today where if you do go down the wrong architecture it is much cheaper to rewrite everything again in something that is better?

Re: Laws of Software Engineering

#307

Post by ActivePattern »

RivieraKid wrote: post #183
danparsonson wrote: post #45

Earlier quoted context omitted.

Features arise out of the composition of fundamental units of the system, they're not normally first class units themselves. Can you give an example?

For example using nested .gitignore files vs using one root .gitignore file. I guess this principle is related to this one: Imagine the code as a graph with nodes and edges. The nodes should be grouped in a way that when you display the graph with grouped nodes, you see few edges between groups. Removing a group means that you need to cut maybe 3 edges, not 30. I.e. you don't want something where every component has…

You're describing "modularity" or "loose coupling" in code. But it rarely implies you can just delete files or directory. It usually just means that a change in one component requires minimal changes to other components -- i.e. the diff is kept small.

Re: Laws of Software Engineering

#308

Post by estimator7292 »

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

Shellac is both a floor polish and a food additive, particularly in candy.

Used to be, anyway. Modern alternatives are much better. It's still used as glue in wind instruments though.

Re: Laws of Software Engineering

#310

Post by otterley »

rapnie wrote: post #113
inetknght wrote: post #80

Earlier quoted context omitted.

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

Really? It's at practically every hardware store I've been to (US, things may be different elsewhere).
Post reply on HN