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

351–360 of 554 posts

Re: Laws of Software Engineering

#351

Post by bluGill »

tombert wrote: post #339
bluGill wrote: post #336

Earlier quoted context omitted.

I've seen a lot of requests to obtimize code where we can measure the optimal versions saves a few nanoseconds. I just deleted some 'optimal code' that took a lot of mutexes and so was only faster when there is no contetion but in real world multi-writer situations the easy code wins. (Shared memory vs local socket for ipc)

I don't write a lot of super low level stuff, so maybe things are different there, but at least in the normal user space level I've found it pretty rare that explicit mutexes ever beat the performance of an (in my opinion) easier design using queues and/or something like ZeroMQ. Generally I've found that the penalty, even without contention, is pretty minimal, and it almost always wins under contention.

To be fair the code in question was written many years ago - before anyone I know had heard of zeromq (it existed but wasn't known). it would be possible to optimize the mutexs out I'm sure - but the big problem wasn't speed it was complexity of code that I now maintain. Since local sockets are easier and faster I'm safe deleting the more complex code that should have never been written.

Re: Laws of Software Engineering

#352

Post by jimbokun »

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

Another law for the list!

Re: Laws of Software Engineering

#353

Post by jimbokun »

whattheheckheck wrote: post #44
busfahrer wrote: post #30

Earlier quoted context omitted.

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

Rule of 3 will greatly benefit the customer over time as it lessens the probability of bugs and makes adding new features faster.

Re: Laws of Software Engineering

#354

Post by AtNightWeCode »

detectivestory wrote: post #159
Kinrany wrote: post #136

SOLID being included immediately makes me have zero expectation of the list being curated by someone with good taste.

I'm seeing some hate for SOLID in these comments and I am a little surprised. While I don't think it should ever be used religiously, I would much rather work on a team that understood the principles than one that didn't.

I think the baseline is that code can be trash and still comply with SOLID. Therefor people get frustrated over it. Getting PR:s rejected and so on.

I think it is better to have real requirements like: The code needs to be testable in a simple way.

Re: Laws of Software Engineering

#355

Post by alexjplant »

Sharlin wrote: post #340
alexjplant wrote: post #313

Earlier quoted context omitted.

> "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary beca…

You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance"

Updated my comment to refine my rhetorical intent. Thank you for the call-out.

Re: Laws of Software Engineering

#356

Post by Quarrelsome »

jcgrillo wrote: post #324
Quarrelsome wrote: post #316

Earlier quoted context omitted.

tbf that's not their fault, as long as they were open about the flaws. Business should not have promoted it to a customer facing product. That's just org failure.

I disagree. If you merge code to main you immediately lose all control over how it will be used later. You shouldn't ever ship something you're not comfortable with, or unprepared to stake your professional reputation on. To do so is profoundly unethical. In a functioning engineering culture individuals who behave that way would be personally legally liable for that decision. Real professions--doctors, engineers, etc…

Profoundly unethical? Ok so wtf is this formatting in your comment. You DARE comment, online where people can see, where you start a new sentence with two dashes "--". What are you thinking? Where's the professionalism? Imagine someone took that sentence and put it on the front of the biggest magazine in the world. You'd LOOK LIKE A FOOL.

OR, perhaps its the case that different contexts have different levels of effort. Running a spike can be an important way to promote new ideas across an org and show how things can be done differently. It can be a political tool that has positive impact, because there's a lot more to a business than simply writing good code. However if your org is horrible then it can backfire in the way that was described. Maybe business are too aggressive and trample on dev, maybe dev doesn't have a spine, maybe nobody spoke up about what a fucking disaster it was going to be, maybe they did and nobody listened. Those are all organisational issues akin to an exploitable code base but embedded into the org instead of the code.

These issues are not the direct fault of the spike, its the fault of the org, just like the idiot that took your poorly formatted comment and put it on the front page of Vogue.

Re: Laws of Software Engineering

#357

Post by darccio »

I wonder if it's usual for other professions/fields to have this tendency to create laws/aphorisms so ingrained. I'm biased as software engineer but it seems to me that is more common in computer science than others.

Re: Laws of Software Engineering

#358

Post by didgetmaster »

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.

I once interviewed at Microsoft. The hiring manager asked me how I would go about programming a break point if I were writing a debugger. I started to explain how I would have to swap out an instruction to put an INT 3 in the code and then replace it when the breakpoint would hit.

He stopped me an said he was just looking to see if I knew what an INT 3 was. He said few engineers he interviewed had any idea.

Re: Laws of Software Engineering

#359

Post by shimman »

deaux wrote: post #230

Laws of Software Engineering (2026 Update) - Every website will be vibecoded using Claude Opus This will result in the following: - The background color will be a shade of cream, to properly represent Anthropic - There will be excessive use of different fonts and weights on the same page, as if a freshman design student who just learned about typography - There will be an excess of cards in different styles, a notewo…

Yeah, the dude vibe coding the site also likely vibe coded the book. Instant pass. Also looking up this person's coding history (mostly cheat sheets and road maps), zero confidence that anything is worthy of note in the book.

Re: Laws of Software Engineering

#360

Post by jcgrillo »

Quarrelsome wrote: post #356
jcgrillo wrote: post #324

Earlier quoted context omitted.

I disagree. If you merge code to main you immediately lose all control over how it will be used later. You shouldn't ever ship something you're not comfortable with, or unprepared to stake your professional reputation on. To do so is profoundly unethical. In a functioning engineering culture individuals who behave that way would be personally legally liable for that decision. Real professions--doctors, engineers, etc…

Profoundly unethical? Ok so wtf is this formatting in your comment. You DARE comment, online where people can see, where you start a new sentence with two dashes "--". What are you thinking? Where's the professionalism? Imagine someone took that sentence and put it on the front of the biggest magazine in the world. You'd LOOK LIKE A FOOL. OR, perhaps its the case that different contexts have different levels of effor…

Grammatical errors, formatting mistakes, or bad writing in general aren't something the magazine publisher can be held liable for, it may be embarrassing but it's not illegal or unethical. Publishing outright falsehoods about someone is though--we call that defamation. Knowingly shipping a broken, insecure system isn't all that different. Of course the people who came along later and chucked it into prod without actually reviewing it were also negligent, but that doesn't render the first guy blameless.
Post reply on HN