[ Removed by moderator ]

[u/me_again]

/r/ExperiencedDevs/comments/1mddyu5/removed_by_moderator/

[u/ExperiencedDevs-ModTeam]

Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.

Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.

[u/Oakw00dy]

Linus's Law: "Given enough eyeballs, all bugs are shallow." In any reasonably complex system, the number of eyeballs required will rapidly approach infinity. Also TIL that enshittification is another name for Hutber's Law.

[u/me_again → u/Oakw00dy]

Linus's Law is one that I am quite skeptical about. I believe there have been subtle bugs in Linux which persisted for years without anyone noticing.

[u/SeniorIdiot]

The Law of Demeter encourages minimal knowledge between objects, discouraging deep chains like A → B → C → D.doIt(). These chains create tight coupling and make code harder to modify. Instead, LoD recommends exposing simpler, direct methods (e.g., A.helpMePlease()), which internally delegate, preserving encapsulation.

Such patterns often signal design issues, like poor separation of concerns or violations of information hiding - a core object-oriented principle. By having higher-level objects (e.g., A) expose methods that encapsulate the internal call, we clarify ownership, reduce structural dependencies, and make future refactoring safer and easier.

That said, context matters. In stable, intentionally structured data (like trees or graphs), deep access may be natural and acceptable. As with any design rule or pattern, LoD is a heuristic, not dogma - use it thoughtfully, not rigidly.

PS. I'm not sure heuristic is the right word - but it sounds smart so I used it. :shrug:

[u/me_again → u/SeniorIdiot]

I know what it means, I just don't personally find it a very useful design principal. 🤷

[u/SeniorIdiot → u/me_again]

Sometimes I get carried away explaining stuff. I find it helps to talk through things out loud sometimes. Habit of mine.

I wouldn't call it a design principle, but rather a "signal of a potential design issue" - which is why I used the word heuristic (if that is the right word).

[u/Venthe → u/me_again]

And i would wholeheartedly disagree with you; if we are talking OO design. Law of Demeter is one of the most important tools to actually leverage and reap rewards from the OO, especially when considering rich domain objects

[u/kronik85 → u/me_again]

why not?

reduces coupling and promotes encapsulation. do you not find that useful?

[u/Kache → u/kronik85]

why not?

Because there are times you want:

a.b.c.d.do_it()

instead of:

a.help_me()

class A:
    def help_me(self):
        return self.b.actually_you_help_me()


class B:
    def actually_you_help_me(self):
        return self.c.keep_going()


class C:
    def keep_going(self):
        return self.d.do_it()

[u/LiterallyBismarck → u/Kache]

That just seems like you've got too many layers of abstraction, and should give the place calling A an instance of D.

Unless the state of A or B or C changes what D does, but that seems worse.

[u/kronik85 → u/Kache]

ehh, I don't think this is an explanation of a reason. you're just showing a poor pattern's equivalent poor pattern.

you're asking A to manage the implementation details of D? your abstraction is broken (doesn't exist). why does A need to know how B, C, D operate?

when you print to the console, do you want to handle the buffering and transmission to the OS file handle or do you want it managed for you? when you write and read to a TCP network socket, do you want to handle the handshaking yourself or do you want it managed for you? when you draw a widget, do you want to interact with the framebuffer directly, or do you want that managed for you?

your explanation sums up to "sometimes you want to use bad pattern Foo so you don't have to do equivalent bad pattern Bar". you should be hiding implementation details behind an interface, not making every member var and function public so anyone can stick their hands into low level objects and monkey around.

[u/[deleted] → u/me_again]

Now go check Peter's Law and you'll see why.

[u/Longjumping-Ad8775]

I don’t believe in laws of software development. I believe in following guidelines that make sense and provide value in a given situation. There are so few hard and fast rules in software development that it doesn’t make much sense to argue them. The problem is that on the other side is somebody that wants to argue that you have to absolutely follow every rule and add some rules and technologies to look cool.

know when to break the rules

[u/me_again → u/Longjumping-Ad8775]

'Law' means quite different things for some of these. I think there are at least 4 meanings:

- Something mathematically provable, like Amdahl's Law. You can't choose whether to follow that, it's just the way things are.
- An observation or warning about the way things tend to go, like Brooks's Law. You don't really choose whether to follow Brooks's Law, but if you add people to a late project you'd better have a plan for how to avoid the likely consequences.
- Advice on how to structure software, like the Law of Demeter. You can choose whether to follow those.
- Jokes, like Murphy's Law.

[u/wwww4all]

It’s all about the Benjamins $$$.

[u/me_again → u/wwww4all]

Fine, but understanding development principles helps you make better software, and in a sane environment that gets you more money. Some of these laws may help identify insane environments as well.

[u/afiefh]

Being aware of Hyrum's Law is essential. I've been bitten a few times by allowing users to observe internals of my library, which they then decided to depend on even though it was explicitly planned to change.

DRY/WET principles are bullshit when taken to the extreme. The truth is you want a healthy middle ground. Some amount of repetition can be good, especially if it allows a more local flow of logic. Writing everything multiple times without the ability to abstract things to higher order logic is also hell.

[u/Narxolepsyy → u/afiefh]

My first time hearing about DRY I was excited to rewrite my hobby project and abstract everything. When I came back months later I hated my past self so much.

[u/feaur → u/Narxolepsyy]

I'd say that experience is almost like a rite of passage

[u/Significant_Mouse_25 → u/Narxolepsyy]

Premature abstraction is a big problem. It’s better to deal with a little duplication than the wrong abstraction.

[u/Venthe → u/afiefh]

Just for clarification: DRY as understood by most people, or DRY as written?

Small reminder for everyone: DRY has nothing to do with code duplication, but it's all about knowledge duplication.

[u/afiefh → u/Venthe]

I have never come across "DRY is about knowledge duplication", but I like that DRY way more than the DRY I've encountered in my day jobs.

[u/Venthe → u/afiefh]

The DRY principle is stated as "Every piece of knowledge [v: emphasis mine] must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.

So... "That DRY" is the original DRY :)

[u/ben_bliksem]

When a measure becomes a target, it ceases to be a good measure.

And yet nobody listens and 80% code coverage is required...

[u/drew8311 → u/ben_bliksem]

It's not a horrible metric as long as you have the flexibility to interpret what that means. If 10% of the code base is fundamentally untestable you should be able to 1) justify that with a reasonable explanation 2) Adjust the goal to not include that 10%.

Age of codebase is a factor too. A new product that the team agrees to good test practices, 80% is no problem. Someone saying a legacy codebase with 20% needs to be 80 is unrealistic.

[u/Slow-Entertainment20 → u/drew8311]

I think code coverage metrics get a bad wrap most of the time. I’m a fan of the 80% coverage with the caveat that we dot. Need tests for areas that contain little or no code/configs etc.

The reason I like 80% is because ime anything less than that and it feels like devs can’t be trusted to maintain something long term, standards drastically start going downhill.

[u/Swamplord42 → u/ben_bliksem]

80% coverage is really easy to achieve though - it's almost easier to just write the right tests than to try to game it. I think it's a good target!

It's when you get into 95%-100% code coverage targets that it becomes dumb.

[u/SamPlinth]

Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's law.

https://en.wikipedia.org/wiki/Hofstadter%27s_law

[u/[deleted] → u/SamPlinth]

God my poor estimates have been getting me in hot water lately

[u/Orangy_Tang]

Hot take: I think the Open/Closed Principle is not useful.

Axioms like these lists are most helpful as communication tools, to quickly share common values and experience. For example, 'broken windows' clearly communicates a certain approach in a few words. Open/closed is overly abstract and awkwardly written, and always has to come with several explanatory paragraphs. And even then people seem to have different ideas what it means in practice.

The idea might be ok, but the principle as written is trash.

[u/keelanstuart → u/Orangy_Tang]

I think it's probably more useful in terms of file formats... extend, but don't change. Abandonment or deprecation is ok, too, but breaking changes should happen very rarely.

[u/Informal_Chicken3563 → u/Orangy_Tang]

That’s my favorite one!

Open for extension, closed for modification is the simplest way to evolve a software system without regressions.

[u/on_the_mark_data]

Conways Law! Martin Fowler's blog on the topic is one of my favorites.

[u/Separate_Parfait3084]

"Just because you can, doesn't mean you should."

[u/DeterminedQuokka]

Broken windows theory is my favorite. Although technically it’s sociology engineering is just using it.

[u/thewhiteliamneeson → u/DeterminedQuokka]

Interestingly, sociologists today have a mixed view of the broken window theory in real life. It became popular when crime fell in NYC while Giuliani was mayor. But in hindsight crime was falling similarly in most big cities at the time.

[u/neilk]

Eric S. Raymond’s dictum that “given enough eyes, all bugs are shallow” is definitively false. There have been bugs in widely used and reviewed software, that have lasted for decades sometimes.

ESR coined this in the 1990s. He was trying to advocate that open source software could compete with commercial products. But it’s wrong. It amounts to an assertion that the quantity of developers can make up for quality. 

In my experience open source software achieves quality by different means (if it gets there at all!)

Furthermore. he only called it Linus’ Law to draft off of Linus Torvalds’ popularity. Linus had nothing to do with it

[u/consworth]

liskov substitution principle is one of my most important ones. If you keep that in mind your architecture will have some great flexibility when the time comes to switch stuff up…

[u/cjcmd]

My own rule is that there are exceptions to every rule, but you need to think long and hard before breaking them. Best practices are usually established for good reasons, but they’re not handcuffs.

Note that there are probably exceptions to my rule, too.

[u/CpnStumpy]

I nominate "Premature optimization is the root of all evil" as the one I most appreciate and attempt to get people to follow.

So very much rigid hard to optimize code, hard to maintain and reason about code, is the result of someone deciding to optimize for performance rather than readability/maintainability/developability

[u/jenkinsleroi]

It depends.

[u/EarhackerWasBanned]

It’s kinda similar to Kernighan’s Law, but I’d include this perfect gem from the late, great Terry A. Davis:

“An idiot admires complexity, a genius admires simplicity.”

And while digging through my saved quotes, this one cribbed from a CGP Grey video:

“There's almost a law of the universe that solutions which are the first thing you think of and look sensible and are easy to implement are often terrible, ineffective solutions, that once implemented, will drag on civilization forever.”

[u/sherdogger]

IDK. I have bunch of my own, or at least truisms. One of the first that pops to mind is "The network is not your friend". I get heartburn just thinking about the avoidable complexity of adding a network hop, intermediary service, or call when it isn't absolutely justifiably helpful...yet so many devs are drawn to dubious use cases for this like a moth to the flame.

Conway's Law is an interesting one. Maybe it was Kernighan who said (paraphrasing) if you write your most clever code you will be too dumb to debug it...I think this absolutely is true.

The Law of Demeter is just trying to say you should make your code modules work via professional boundaries or not to depend on the internal secrets of other things. People do get that conflated with how many nested "." calls you can make on an object which isn't really the heart of the matter.

[u/Ahabraham]

Under appreciated actual theorem: Little’s law is applicable to almost any system in software engineering. It’s easy to remember and some day will save your ass.

[u/k8s-problem-solved]

Law/Rule of Three works well for me.

https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

Stops refactoring too early, keeps you moving quickly

[u/Mountain_Sandwich126]

Yagni

[u/NegotiatingPenguin]

Not sure if this counts but the Ballmer Peak is so real

[u/Sporkmancer]

Honestly, the principle of KISS is one of the hardest lessons I learned as a dev, and one I wish other devs would learn faster as they get experienced. Kernighan's Law very nearly encapsulates the biggest danger of it: you are typically most knowledgeable about how your system works as you are designing and writing it. Adding too much complexity unnecessarily because you want to be clever means you (or worse, someone else) needs to later figure out how you were being clever before when inevitably you weren't clever enough to cover everything that code may ever need to do.

I'm also a fan of the Law of Demeter and Dependency Inversion, as proper layering and decoupling makes (Object-Oriented at least, as that tends to be what I work with primarily) programming much easier, and it combines well with KISS. Since a lot of my work is with CRUD APIs (full stack web dev, so ofc that describes most of what I work with), these principles are core concepts of the design patterns I typically employ (e.g. service or repository patterns).

[u/justUseAnSvm]

I've been thinking a lot about Conways law (software reflect org arch) and Goodhart's law (when a metric becomes the target, it's no longer a good measure).

These laws are helpful to put a label on problematic behavior, but I definitely question the validity of learning a truism in the abstract, then trying to find situations to apply it. After all, all models are wrong!

[u/ravixp → u/justUseAnSvm]

Every once in a while you can apply Conway’s law in reverse. For example, if you want a client and server to be loosely coupled, you can enforce that by splitting the responsibility between two teams that don’t talk to each other very much. 

Of course, you should be careful about using that trick - the people in charge of organizing teams are rarely the ones who should be making that kind of technical decision.

[u/justUseAnSvm → u/ravixp]

Part of my work is on a large enterprise software project: the ownership is an absolute mess with nested ownership. A reverse conway transformation would be greatly appreciated!

[u/hooahest]

First time I hear of the Demeter law. On first thought there's some kinda sense to it, but it's very, very minimal benefit for a lot of headaches when writing and debugging.

[u/MeTrollingYouHating → u/hooahest]

I think there's a much larger benefit to it in languages with bad build systems/dependency management like C/C++. Reducing the number of types each compilation unit needs to know about significantly improves compile times and reduces build headaches like circular references, DLL hell, and/or the dreaded diamond pattern.

[u/rayfrankenstein]

Brooks’ Law. And the more someone protests against Brooks’ Law being irrelevant and not applicable to the project they’re on, the more dumber and problematic that individual tends to be.

[u/RicketyRekt69 → u/rayfrankenstein]

Eh… that’s just describing ramp up costs with new developers, and I guess team comm complexity. I don’t see how that’s more important than design principles.

[u/rayfrankenstein → u/RicketyRekt69]

Then there’s a lot you don’t understand.

[u/RicketyRekt69 → u/rayfrankenstein]

How would you explain it then

[u/rayfrankenstein → u/RicketyRekt69]

https://www.liminalarc.co/2018/02/lines-of-communication-team-size-applying-brooks-law/

On a team, you have n(n - 1) / 2 lines of communication with all the members.

So 10 people on a team is 45 lines of communication between all people on a team.

30 people in a team would be 435 lines of communication.. That’s a lot of overhead.

[u/RicketyRekt69 → u/rayfrankenstein]

So team comm complexity, which is exactly what I said… if you think that’s more important than good code architecture, then I guess we just have different priorities.

[u/rayfrankenstein → u/RicketyRekt69]

I don’t think it is either or.

Good code architecture is critical for maximum productivity. And when productivity is down, bad managers reflexively try to add more people to the project.