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

41–50 of 554 posts

Re: Laws of Software Engineering

#41

Post by Antibabelic »

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…

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 company employees. Software engineering needs to grow up, have real certification and standards bodies and start being rigorously regulated, unless you want to rely on blind hope that your "general" has been putting an "honest effort" and showing basic competence.

Re: Laws of Software Engineering

#42

Post by sverhagen »

kijin wrote: post #33
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.

What's the smallest unit of functionality to which your principle applies? For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?

Maybe the buttons shouldn't be their own files, but the backend functionality certainly could be. I don't do this, but I like the idea.

Re: Laws of Software Engineering

#43

Post by layer8 »

grahar64 wrote: post #3

Some of these laws are like Gravity, inevitable things you can fight but will always exist e.g. increasing complexity. Some of them are laws that if you break people will yell at you or at least respect you less, e.g. leave it cleaner than when you found it.

Physical laws vs human laws.

Re: Laws of Software Engineering

#44

Post by whattheheckheck »

busfahrer wrote: post #30
AussieWog93 wrote: post #25

Earlier quoted context omitted.

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

Why 3? What is this baseball?

Take the 5 Rings approach.

The purpose of the blade is to cut down your opponent.

The purpose of software is to provide value to the customer.

It's the only thing that matters.

You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment

Re: Laws of Software Engineering

#45

Post by danparsonson »

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.

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?

Re: Laws of Software Engineering

#46

Post by WillAdams »

ghm2180 wrote: post #14
ozgrakkurt wrote: post #9

For anyone reading this. Learn software engineering from people that do software engineering. Just read textbooks which are written by people that actually do things

Any recommendations? I read designing data intensive applications(DDIA) which was really good. But it is by Martin Klepmann who as I understand is an academic. Reading PEPs is also nice as it allows one to understand the motivations and "Why should I care" about feature X.

Ousterhout's _A Philosophy of Software Design_ (mentioned elsethread) would be mine.

Re: Laws of Software Engineering

#47

Post by mcv »

busfahrer wrote: post #30
AussieWog93 wrote: post #25

Earlier quoted context omitted.

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

I once heard of a counter-principle called WET: Write Everything Twice.

Re: Laws of Software Engineering

#48

Post by jpitz »

kijin wrote: post #33
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.

What's the smallest unit of functionality to which your principle applies? For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?

I think that if you continue along the logical progression of the parent poster, then maybe the smaller units of functionality would be represented by simple ranges of lines of text. Given that, deleting a single button would ideally mean a single contiguous deletion from a file, versus deleting many disparate lines.

Re: Laws of Software Engineering

#49

Post by [deleted] »

dataviz1000 wrote: post #5

I did not see Boyd’s Law of Iteration [0] "In analyzing complexity, fast iteration almost always produces better results than in-depth analysis." Boyd invented the OODA loop. [0] https://blog.codinghorror.com/boyds-law-of-iteration/

[deleted]

Re: Laws of Software Engineering

#50

Post by iwontberude »

AussieWog93 wrote: post #25
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

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

Why do the have to be so smart but so annoying at the same time?
Post reply on HN