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

81–90 of 554 posts

Re: Laws of Software Engineering

#83

Post by rustyhancock »

blandflakes wrote: post #75
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

This was also true of Amazon's Leadership Principles. They are pretty reasonable guidelines, but in a debate, it really came down to which one you could most reasonably weaponize in favor of your argument, even to the detriment of several others. Which maybe is also fine, I dunno :)

It's because they are heurists intended to be applied by knowledgeable and experienced humans.

It can be quite hard to explain when a student asks why you did something a particular way. The truthful answer is that it felt like the right way to go about it.

With some thought you can explain it partly - really justify the decision subconsciously made.

If they're asking about a conscious decision that's rarely much more helpful that you having to say that's what the regulations, or guidelines say.

Where they really learn is seeing those edge cases and gray areas

Re: Laws of Software Engineering

#84

Post by arnorhs »

asdfasgasdgasdg wrote: post #81
bakkerinho wrote: post #70

> This site was paused as it reached its usage limits. Please contact the site owner for more information. Law 0: Fix infra.

Law 1: caching is 90-99% of performance.

are you saying performance is 90-99% caching? If so that is so obviously untrue.

If you are saying you _can_ fix 90-99% of performance bottlenecks eventually with caching, that may be true, but doesn't sound as nice

Re: Laws of Software Engineering

#86

Post by CuriouslyC »

stingraycharles wrote: post #8
tmoertel wrote: post #7

One that is missing is Ousterhout’s rule for decomposing complexity: complexity(system) = sum(complexity(component) * time_spent_working_in(component) for component in system). The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.

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.

I think the intent is that if you can cleanly encapsulate some complexity so that people working on stuff that uses it don't have to understand anything beyond a simple interface, that complexity "doesn't exist" for all intents and purposes. Obviously this isn't universal, but a fair percentage of programmers these days don't understand the hardware they're programming against due to the layers of abstractions over them, so it's not crazy either.

Re: Laws of Software Engineering

#87

Post by dgb23 »

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

> In many cases, simpler code is faster, and fast code makes for simpler systems. (...)

I wholeheartedly agree with you here. You mentioned a few architectural/backend issues that emerge from bad performance and introduce unnecessary complexity.

But this also happens in UI: Optimistic updates, client side caching, bundling/transpiling, codesplitting etc.

This is what happens when people always answer performance problems with adding stuff than removing stuff.

Re: Laws of Software Engineering

#90

Post by CodesInChaos »

xnorswap wrote: post #34
layer8 wrote: post #32

Earlier quoted context omitted.

DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.

I like this a lot more, because it captures whether two things are necessarily the same or just happen to be currently the same. A common "failure" of DRY is coupling together two things that only happened to bear similarity while they were both new, and then being unable to pick them apart properly later.

> then being unable to pick them apart properly later.

Which is often caused by the "midlayer mistake" https://lwn.net/Articles/336262/

Post reply on HN