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

361–370 of 554 posts

Re: Laws of Software Engineering

#361

Post by fragmede »

Shorel wrote: post #315
jcgrillo wrote: post #208

Earlier quoted context omitted.

Reminds me of a codebase that was littered with SQL injection opportunities because doing it right would have been "premature optimization" since it was "just" a research spike and not customer facing. Guess what happened when it got promoted to a customer facing product?

Now that's an stupid argument. I'm with you. Removing SQL injection has little if anything to do with performance, so it is not an optimization. I guess we will get more of this with the vibe coding craze.

We'll see. It's easy enough to ask Claude to red team and attack the system given the codebase and see what holes it finds to patch up. It's good enough now to find blatantly obvious shit like an SQL injection.

Re: Laws of Software Engineering

#362

Post by 4dregress »

I like to replace the bus factor with the Lottery Factor.

I actually had a college run over by a bus on the way to work in London, was very lucky and made a full recovery.

Head poking out under the main exit of the bus.

Re: Laws of Software Engineering

#363

Post by Quarrelsome »

jcgrillo wrote: post #360
Quarrelsome wrote: post #356

Earlier quoted context omitted.

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

If it was only supposed to be a spike then it does render the first guy somewhat blameless. Especially if the org was made aware of the issues, which I imagine they were if someone had raised the issue of the exploits in the code base.

I mean I could take a toddlers tricycle and try to take it onto the motorway. Can we blame the toy company for that? It has wheels, it goes forward, its basically a car, right? In the same way a spike is basically something we can ship right now.

Re: Laws of Software Engineering

#364

Post by rapnie »

otterley wrote: post #310
rapnie wrote: post #113

Earlier quoted context omitted.

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

Yes, Netherlands, think it is quite different in retail in comparison.

Re: Laws of Software Engineering

#366

Post by pkasting »

omoikane wrote: post #257
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)

(Tangent: What a pleasure to see your username again; will always think of your readability help fondly!)

Re: Laws of Software Engineering

#367

Post by ryandrake »

zaphar wrote: post #295
physicles wrote: post #272

Earlier quoted context omitted.

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…

I probably use a different interpretation of Postel's law. I try not "break" for anything I might receive, where break means "crash, silently corrupt data, so on". But that just means that I return an error to the sender usually. Is this what Postel meant? I have no idea.

Yea, I interpret it as the same thing: On invalid input, don't crash or give the caller a root shell or whatever, but definitely don't swallow it silently. If the input is malformed, it should error and stop. NOT try to read the user's mind and conjure up some kind of "expected" output.

Re: Laws of Software Engineering

#368

Post by ryandrake »

davedx wrote: post #205
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

As a very senior SWE with a decent amount of eng decision making responsibility these days I still find I get so much mileage out of KISS and YAGNI that I never really think about any other laws. So much SWE is overengineering. Just like this website to be honest. You don't get away with all that bullshit in other eng professions where your BoM and labour costs are material.

I always thought it would be great if every line of software (or, chose some other unit of complexity) added to the unit cost of creating each copy. Like every bolt or gasket adds a few cents the the BOM of a piece of hardware. That fictional world would have simple, fast, and higher quality software programs.

Re: Laws of Software Engineering

#369

Post by tshaddox »

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…

> Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment.

Which is pretty close to just saying "don't do anything unless you have a good reason for doing it."

Re: Laws of Software Engineering

#370

Post by t43562 »

The conservation of Complexity (Tesler) seems immediately insightful to me just as a sentence:

  "Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated."
But then in the explanation seems to me to devolve down to a trite suggestion not to burden your users. This doesn't interest me because users need the level of complexity they need and no more whatever you're doing and making it less causes your application to be an unflexible toy. So this is all, to a degree, obvious.

I think it's more useful to remember when you're refactoring that if you try to make one bit of a system simpler then you often just make another part more complex. Why write something twice to end up with it being just as bad the other way round?

Post reply on HN