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

521–530 of 554 posts

Re: Laws of Software Engineering

#521

Post by bartread »

Shorel wrote: post #501
bartread wrote: post #405

Earlier quoted context omitted.

I believe use of Electron is known as premature deoptimisation and if it had been a thing when Knuth coined the original phrase I'm sure he would have come up with that term too. Use of Electron to deliver software is popular and works but that doesn't make it any less of an abomination. I'm actually considering, for the first time since 2013/14 when I worked on a Visual Studio extension, creating a piece of desktop…

I am testing Slint for exactly the same thing. An alternative to Qt/wxWidgets. It is written in Rust.

Slint? Interesting: I will have to investigate.

Re: Laws of Software Engineering

#523

Post by ragnese »

kortex wrote: post #435
ragnese wrote: post #387

Earlier quoted context omitted.

I don't think that interpretation makes that much sense. Isn't it a bit too... obvious that you shouldn't just crash and/or corrupt data on invalid input? If the law were essentially "Don't crash or corrupt data on invalid input", it would seem to me that an even better law would be: "Don't crash or corrupt data." Surely there aren't too many situations where we'd want to avoid crashing because of bad input, but we'd…

I actually dont think it's that obvious at all (unless you are a senior engineer). It's like the classic joke: A QA engineer walks into a bar and orders a beer. She orders 2 beers. She orders 0 beers. She orders -1 beers. She orders a lizard. She orders a NULLPTR. She tries to leave without paying. Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drin…

Hmm. Fair point. It's entirely possible that it's not obvious and that the "law" is almost a "reminder" of sorts to not assume you're getting well-formed inputs.

I'm still skeptical that this is the case with Postel's Law, but I do see that it's possible to read it that way. I guess I could always go do some research to prove it one way or the other, but... nah.

And yes, "Parse, don't validate." is one of my absolute favorite maxims (good word choice, by the way; I would've struggled on choosing a word for it here).

Re: Laws of Software Engineering

#524

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

#525

Post by xnx »

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

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

More like the Bible of Software Engineering then

Re: Laws of Software Engineering

#526

Post by tsoukase »

m463 wrote: post #428
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.”

As a computer person, I hated math/physics/science because of the one-letter (greek) variable names. Of course some of that osmosizes back via lisp and APL.

That was the exact reason I liked math. Maybe because I am Greek.

Re: Laws of Software Engineering

#527

Post by traderj0e »

regular_trash wrote: post #430
traderj0e wrote: post #415

Earlier quoted context omitted.

YAGNI is usually about modularization, often in response to Java-style OOP obsession. Like you don't need to define some big protocol that's only ever going to have one implementation.

Well this is not the context I had in mind. I'm thinking of the many times I've had to break apart 3kloc react components to reuse some part just because someone decided modularity didn't matter

I mean YAGNI is usually about modularization in general, so yeah a React component would be included in that, it's not limited to just OOP. 3K loc is probably well beyond the point where it should've been split up.

Re: Laws of Software Engineering

#528

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

#529

Post by jrmiii »

hatsix wrote: post #224

I know it's not software-engineering-only, but Chesterton's Fence is often the first 'law' I teach interns and new hires: https://fs.blog/chestertons-fence/

Found your comment by searching to see if anyone mentioned it. Really key in legacy systems.
Post reply on HN