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

51–60 of 554 posts

Re: Laws of Software Engineering

#51

Post by fenomas »

Nice to have these all collected nicely and sharable. For the amusement of HN let me add one I've become known for at my current work, for saying to juniors who are overly worried about DRY:

> Fen's law: copy-paste is free; abstractions are expensive.

edit: I should add, this is aimed at situations like when you need a new function that's very similar to one you already have, and juniors often assume it's bad to copy-paste so they add a parameter to the existing function so it abstracts both cases. And my point is: wait, consider the cost of the abstraction, are the two use cases likely to diverge later, do they have the same business owner, etc.

Re: Laws of Software Engineering

#52

Post by layer8 »

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.

Functionalities aren’t necessarily orthogonal to each other; features tend to interact with one another. “Avoid coupling between unrelated functionalities” would be more realistic.

Re: Laws of Software Engineering

#53

Post by mcv »

layer8 wrote: post #32
pydry wrote: post #29

Earlier quoted context omitted.

DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when t…

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.

That's how I understood it. If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY.

Re: Laws of Software Engineering

#55

Post by ndr »

fenomas wrote: post #51

Nice to have these all collected nicely and sharable. For the amusement of HN let me add one I've become known for at my current work, for saying to juniors who are overly worried about DRY: > Fen's law: copy-paste is free; abstractions are expensive. edit: I should add, this is aimed at situations like when you need a new function that's very similar to one you already have, and juniors often assume it's bad to copy…

Same vibe, different angle:

> 11. Abstractions don’t remove complexity. They move it to the day you’re on call.

Source: https://addyosmani.com/blog/21-lessons/

Re: Laws of Software Engineering

#56

Post by devgoncalo »

ghm2180 wrote: post #14
ozgrakkurt wrote: post #9

For anyone reading this. Learn software engineering from people that do software engineering. Just read textbooks which are written by people that actually do things

Any recommendations? I read designing data intensive applications(DDIA) which was really good. But it is by Martin Klepmann who as I understand is an academic. Reading PEPs is also nice as it allows one to understand the motivations and "Why should I care" about feature X.

The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Re: Laws of Software Engineering

#57

Post by Sergey777 »

A lot of these “laws” seem obvious individually, but what’s interesting is how often we still ignore them in practice.

Especially things like “every system grows more complex over time” — you can see it in almost any project after a few iterations.

I think the real challenge isn’t knowing these laws, but designing systems that remain usable despite them.

Re: Laws of Software Engineering

#58

Post by Xiaoher-C »

fenomas wrote: post #51

Nice to have these all collected nicely and sharable. For the amusement of HN let me add one I've become known for at my current work, for saying to juniors who are overly worried about DRY: > Fen's law: copy-paste is free; abstractions are expensive. edit: I should add, this is aimed at situations like when you need a new function that's very similar to one you already have, and juniors often assume it's bad to copy…

[dead]

Re: Laws of Software Engineering

#59

Post by James_K »

I feel that Postel's law probably holds up the worst out of these. While being liberal with the data you accept can seem good for the functioning of your own application, the broader social effect is negative. It promotes misconceptions about the standard into informal standards of their own to which new apps may be forced to conform. Ultimately being strict with the input data allowed can turn out better in the long run, not to mention be more secure.

Re: Laws of Software Engineering

#60

Post by Xiaoher-C »

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

[dead]
Post reply on HN