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

251–260 of 554 posts

Re: Laws of Software Engineering

#251

Post by pc86 »

msla wrote: post #180
iamflimflam1 wrote: post #151

Earlier quoted context omitted.

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

> Similar to the "code should be self documenting - ergo: We don't write any comments, ever" My counterpoint: Code can be self-documenting, reality isn't. You can have a perfectly clear method that does something nobody will ever understand unless you have plenty of documentation about why that specific thing needs to be done, and why it can't be simpler. Like having special-casing for DST in Arizona, which no other…

This isn't a counterpoint, it's just additional (and barely relevant) information.

Re: Laws of Software Engineering

#254

Post by afpx »

f1shy wrote: post #229
iamflimflam1 wrote: post #151

Earlier quoted context omitted.

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

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

Re: Laws of Software Engineering

#256

Post by ericmcer »

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

Most of them felt contradictory and kind of antiquated.

Reading through the list mostly made me feel sad. You can't help but interpret these through the modern lens of AI assisted coding. Then you wonder if learning and following (some) of these for the last 20 years is going to make you a janitor for a bunch of AI slop, or force you into a coding style where these rules are meaningless, or make you entirely irrelevant.

Re: Laws of Software Engineering

#257

Post by omoikane »

pkasting wrote: post #215

This list is missing my personal law, Kasting's Law: Asking "who wrote this stupid code?" will retroactively travel back in time and cause it to have been you.

"I'm casting around in my head for someone to blame, and it's just... me, keeps coming back at me."

- Jeremy Clarkson (Top Gear, series 14 episode 5)

Re: Laws of Software Engineering

#258

Post by ericmcer »

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.

DRY and KISS were right next to each other which I thought was funny.

Re: Laws of Software Engineering

#259

Post by toast0 »

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…

I only use mature optimizations, so I'm good.

Thinking about the overall design, how its likely to be used, and what the performane and other requirements are before aggregating the frameworks of the day is mature optimization.

Then you build things in a reasonable way and see if you need to do more for performance. It's fun to do more, but most of the time, building things with a thought about performance gets you where you need to be.

The I don't need to think about performance at all camp, has a real hard time making things better later. For most things, cycle counting upfront isn't useful, but thinking about how data will be accessed and such can easily make a huge difference. Things like bulk load or one at a time load are enormous if you're loading lots of things, but if you'll never load lots of things, either works.

Thinking about concurrency, parallelism, and distributed systems stuff before you build is also pretty mature. It's hard to change some of that after you've started.

Re: Laws of Software Engineering

#260

Post by sandeepkd »

austin-cheney wrote: post #146
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…

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its nece…

This is crucial detail that almost everyone misses when they are skimming the topic on surface. The implication is that this statement/law is referenced more often to shut down the architecture designs/discussions
Post reply on HN