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

141–150 of 554 posts

Re: Laws of Software Engineering

#141

Post by nradov »

ta20240528 wrote: post #72
whattheheckheck wrote: post #44

Earlier quoted context omitted.

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

"The purpose of software is to provide value to the customer." Partially correct. The purpose of your software to its owners is also to provide future value to customers competitively. What we have learnt is that software needs to be engineered: designed and structured.

And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.

Re: Laws of Software Engineering

#142

Post by skydhash »

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.

Now, I tend towards the C idiom of having few files and not a deep structure and away from the one class, one file of Java. Less files to rename when refactoring and less files to open trying to understand an implementation.

Re: Laws of Software Engineering

#143

Post by tananaev »

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…

With modern tools it should be pretty easy to build scalable solutions. I take premature optimization as going out of your way to optimize something that's already reasonable. Not that you should write really bad code as a starting point.

Re: Laws of Software Engineering

#144

Post by bigfishrunning »

cogman10 wrote: post #119

Uhh, I knew I wasn't going to like this one when I read it. > Premature Optimization (Knuth's Optimization Principle) > Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved. This example is the exact example I'd choose where people wrong…

Yeah, for every Knuth there are 10000 copies of schlemiel the painter

Re: Laws of Software Engineering

#145

Post by jcgrillo »

horsawlarway wrote: post #135
jcgrillo wrote: post #127

Earlier quoted context omitted.

Obviously if someone dies or is injured a safety violation has occurred. But other examples include things like data protection failures--if for example your system violates GDPR or similar constraints it is unsafe. If your system accidentally breaks tenancy constraints (sends one user's data to another user) it is unsafe. If your system allows a user to escalate privileges it is unsafe. These kinds of failures are n…

None of those are what OP proposed. Frankly, we also cover many of these practices just fine. What do you think SOC 2 type 2 and ISO 27001 are? It seems like your issue is that we don't hold all companies to those standards. But I'm personally ok with that. In the same way I don't think residential homes should be following commercial construction standards.

> None of those are what OP proposed.

That doesn't worry me overly much.

> What do you think SOC 2 type 2 and ISO 27001 are?

They're compliance frameworks that have little to no consequences when they're violated, except for some nebulous "loss of trust" or maybe in extreme cases some financial penalties. The problem is the expectation value of the violation penalty isn't sufficient to change behavior. Companies still ship code which violates these things all the time.

> It seems like your issue is that we don't hold all companies to those standards.

Yes, and my issue is that we don't hold engineers personally liable for negligent work.

> I don't think residential homes should be following commercial construction standards.

Sure, there are different gradations of safety standards, but often residential construction plans require sign-off by a professional engineer. In the case when an engineer negligently signs off on an unsafe plan, that engineer is liable. Should be exactly the same situation in software.

Re: Laws of Software Engineering

#146

Post by austin-cheney »

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 necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. 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.

Re: Laws of Software Engineering

#147

Post by shermantanktop »

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

Oh! I didn’t have a name for this one, but it’s a lesson I’ve learned. E.g. if variable x is non-zero, then variable y will be set to zero. Don’t check variable y to find out whether x is zero. And definitely don’t repurpose y for some other function in cases where it’s otherwise unused.

Re: Laws of Software Engineering

#148

Post by EGreg »

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 would add this: https://magarshak.com/blog/perfection-is-the-enemy-of-the-go...

Re: Laws of Software Engineering

#149

Post by Sammi »

tananaev wrote: post #143
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…

With modern tools it should be pretty easy to build scalable solutions. I take premature optimization as going out of your way to optimize something that's already reasonable. Not that you should write really bad code as a starting point.

The problem is that that this term gets misused to say the opposite of what it was intended for.

It's particularly the kind of people who like to say "hur hur don't prematurely optimize" that don't bother writing decent software to begin with and use the term as an excuse to write poor performing code.

Instead of optimizing their code, these people end up making excuses so they can pessimize it instead.

Re: Laws of Software Engineering

#150

Post by tehjoker »

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 would venture that this statement is not true for library authors. Performance is a large factor in competitive advantage, especially in domains like image analysis or processing large corpuses of text etc.

In these domains, algorithm selection, and fine tuning hot spots pays off significantly. You must hit minimum speeds to make your application viable.

Post reply on HN