Top
Best
New

Posted by milanm081 4 days ago

Laws of Software Engineering(lawsofsoftwareengineering.com)
1118 points | 507 commentspage 6
kwar13 3 days ago|
Half of these are not about software engineering and just general management principles.
milanm081 4 days ago||
For years, I kept notes on patterns I saw in software projects, architecture, planning, estimation, testing, scaling, and team design.

I pulled those notes into a browsable site with 56 laws, grouped into categories, with short explanations and separate pages for each one.

The goal was simple: put these ideas in one place, so when you want a quick refresher on Conway’s Law, Brooks’s Law, Gall’s Law, Hyrum’s Law, or Goodhart’s Law, you can find it fast.

I’m more interested in criticism than praise. Which laws are missing, which ones feel overstated, and which ones get misused most often in real work?

hpincket 4 days ago||
Time to mention my tongue-in-cheek law:

> When describing phenomena in the social world

> Software Engineers gravitate towards eponymous 'laws'.

https://pincketslaw.com/

cientifico 4 days ago||
There is one missing that i am using as primary for the last 5 years.

The UX pyramid but applied to DX.

It basically states that you should not focus in making something significant enjoyable or convenient if you don't have something that is usable, reliable or remotely functional.

https://www.google.com/search?q=ux+pyramid

toolslive 4 days ago||
maybe add: "the universe is winning" (in the design department). Full quote: "software engineers try to build "idiot-proof" systems, while the universe creates "bigger and better idiots" to break them. So far, the universe is winning"
computerdork 4 days ago||
Don't see a really important one in my opinion: Refactor legacy code, don't rewrite it. All that cruft you see are bug fixes.

Because rewriting old complex code is way more time consuming that you think it'll be. You have to add not only in the same features, but all the corner cases that your system ran into in the past.

Have seen this myself. A large team spent an entire year of wasted effort on a clean rewrite of an key system (shopping cart at a high-volume website) that never worked... ...although, in the age of AI, wonder if a rewrite would be easier than in the past. Still, guessing even then, it'd be better if the AI refactored it first as a basis for reworking the code, as opposed to the AI doing a clean rewrite of code from the start.

namenotrequired 4 days ago|
The “second system effect” page more or less covers this
computerdork 4 days ago||
Ah, think there is overlap, but still not the same in my opinion. Having read this just now, the second system effect seems to be more about not getting overly ambitious in the redesign. What the guideline I mentioned is saying is "don't rewrite, refactor.""

As you probably know, there is a tendency when new developers join a team to hate the old legacy code - one of the toughest skills is being able to read someone else's code - so they ask their managers to throw it away and rewrite it. This is rarely worth it and often results in a lot of time being spent recreating fixes for old bugs and corner cases. Much better use of time to try refactoring the existing code first.

Although, can see why you mentioned it from the initial example that I gave (on that rewrite of the shopping cart) which is also covered by the "second system effect." Yeah, thinking back, have seen this too. Overdesign can get really out of hand and becomes really annoying to wade through all that unnecessary complexity whenever you need to make a change.

satansdeer 4 days ago||
It's proverbs, not laws

Most of them are also wrong

bpavuk 4 days ago||
> This site was paused as it reached its usage limits. Please contact the site owner for more information.

ha, someone needs to email Netlify...

lifeisstillgood 4 days ago|
Just throwing one of my favourites in:

As JFK never said:

“””We do these things, not because they are easy,

But because we thought they would be easy”””

More comments...