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

161–170 of 554 posts

Re: Laws of Software Engineering

#161

Post by skydhash »

Brian_K_White wrote: post #71
stingraycharles wrote: post #8

Earlier quoted context omitted.

That’s not some kind of law, though. And I’m also not sure whether it even makes sense, complexity is not a function of time spent working on something.

It's showing that all the complexity in the components are someone else's problem. Your only complexity is your own top layer and your interface with the components.

Only when the problem has been resolved well enough for your use cases. Like using an http client instead of dealing with parsing http messages or using a GUI toolkit instead of manipulating raw pixels.

That’s pretty much what good design is about. Your solve a foundational problems and now no one else needs to think about it (including you when working on some other parts).

Re: Laws of Software Engineering

#162

Post by galbar »

nradov wrote: post #141
ta20240528 wrote: post #72

Earlier quoted context omitted.

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

These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice.

This is a very costly way of developing software.

Re: Laws of Software Engineering

#163

Post by markburns »

zahlman wrote: post #79
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've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?

I saw a fancy HTML table generator that had so many parameters and flags and bells and whistles that it took IIRC hundreds of lines of code to save writing a similar amount of HTML in a handful of different places.

Yes the initial HTML looked similar in these few places, and the resultant usage of the abstraction did not look similar.

But it took a very long time reading each place a table existed and quite a bit longer working out how to get it to generate the small amount of HTML you wanted to generate for a new case.

Definitely would have opted for repetition in this particular scenario.

Re: Laws of Software Engineering

#164

Post by renticulous »

sigma5 wrote: post #158

I would add also Little's law for throughput calculation https://en.wikipedia.org/wiki/Little%27s_law

Linus's Law : "Given enough eyeballs, all bugs are shallow".

Applies to opensource. But it also means that code reviews are a good thing. Seniors can guide juniors to coax them to write better code.

Re: Laws of Software Engineering

#165

Post by xnx »

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…

> making your code more complicated and still slower than if you thought about performance at the start.

Not if your optimization for performance is some Rube Goldberg assemblage of microservices and an laundry list of AWS services.

Re: Laws of Software Engineering

#166

Post by heap_perms »

Kinrany wrote: post #136

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

That's interesting, what makes you think that? Not long ago, I was working on my degree in Computer Science (Software Engineering), and we were heavily drilled on this principle. Even then, I found it amusing how all the professors were huge fanboys of SOLID. It was very dogmatic.

Re: Laws of Software Engineering

#167

Post by ghosty141 »

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…

What's the problem with SOLID? It's very very rare that I see a case where going against SOLID leads to better design.

Re: Laws of Software Engineering

#168

Post by cogman10 »

_dain_ wrote: post #10

I have a lot of issues with this one: https://lawsofsoftwareengineering.com/laws/premature-optimiz... It leaves out this part from Knuth: >The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreactio…

> I suppose there is a fundamental tradeoff somewhere, but that doesn't mean you're actually at the Pareto frontier, or anywhere close to it. In many cases, simpler code is faster, and fast code makes for simpler systems.

Just a little historic context will tell you what Knuth was talking about.

Compilers in the era of Knuth were extremely dumb. You didn't get things like automatic method inlining or loop unrolling, you had to do that stuff by hand. And yes, it would give you faster code, but it also made that code uglier.

The modern equivalent would be seeing code working with floating points and jumping to SIMD intrinsics or inline assembly because the compiler did a bad job (or you presume it did) with the floating point math.

That is such a rare case that I find the premature optimization quote to always be wrong when deployed. It's always seems to be an excuse to deploy linear searches and to avoid using (or learning?) language datastructures which solve problems very cleanly in less code and much less time (and sometimes with less memory).

Re: Laws of Software Engineering

#169

Post by lamasery »

nradov wrote: post #141
ta20240528 wrote: post #72

Earlier quoted context omitted.

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

Plenty of businesses or products within businesses stagnate and fail because their software got too expensive to maintain and extend. Not infrequently, this happens before it even sees a public release. Any business that can't draw startup-type levels of investment to throw effectively infinite amounts of Other People's Money at those kinds of problems, risks that end if they allow their software to get too messed-up.

The "who gives a shit, we'll just rewrite it at 100x the cost" approach to quality is very particular to the software startup business model, and doesn't work elsewhere.

Re: Laws of Software Engineering

#170

Post by nradov »

galbar wrote: post #162
nradov wrote: post #141

Earlier quoted context omitted.

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

These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice. This is a very costly way of developing software.

It's easy to say that organizations should do it right the first time, in terms of applying proper engineering practices. But they often didn't have the time, capital, and skillset to do that. Not ideal, but that's often how things work in the real world and it will never change.
Post reply on HN