What do you call the law that you violate when you vibe code an entire website for "List of 'laws' of software engineering" instead of just creating a Wikipedia page for it
Slop’s Law
If it can be slopped, it will be slopped.
Laws of Software Engineering
321–330 of 554 posts
Re: Laws of Software Engineering
#322> 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…
Spent 6 months last year ripping out an abstraction layer that made every request 40ms slower. We profiled, found the hot path, couldn't fix it without a rewrite. The "optimize later" school never tells you later sometimes means never
I'd say it usually means "never".
I also find it a bit annoying is that most people just make shit up about stuff that is "faster". Instead of measuring and/or looking at the compiled bytecode/assembly, people just repeat tribal knowledge about stuff that is "faster" with no justification. I find that this is common amongst senior-level people at BigCos especially.
When I was working in .NET land, someone kept telling me that "switch statements are faster" than their equivalent "if" statements, so I wrote a very straightforward test comparing both, and used dotpeek to show that they compile to the exact same thing. The person still insisted that switch is "faster", I guess because he had a professor tell him this one time (probably with more appropriate context) and took whatever the professor said as gospel.
Re: Laws of Software Engineering
#323Not 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.
YES! "Deletability"
Re: Laws of Software Engineering
#324Earlier quoted context omitted.
Reminds me of a codebase that was littered with SQL injection opportunities because doing it right would have been "premature optimization" since it was "just" a research spike and not customer facing. Guess what happened when it got promoted to a customer facing product?
tbf that's not their fault, as long as they were open about the flaws. Business should not have promoted it to a customer facing product. That's just org failure.
I disagree. If you merge code to main you immediately lose all control over how it will be used later. You shouldn't ever ship something you're not comfortable with, or unprepared to stake your professional reputation on. To do so is profoundly unethical. In a functioning engineering culture individuals who behave that way would be personally legally liable for that decision. Real professions--doctors, engineers, etc.--have a coherent concept of malpractice, and the legal teeth to back it up. We need that for software too, if we're actually engineers.
Re: Laws of Software Engineering
#325I like it, but this could have been a tab delimited text file.
Re: Laws of Software Engineering
#326Earlier quoted context omitted.
The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)
On the one hand, in today's world asking how many bits is in an int is exactly as answerable as "how long is a piece of rope" On the other, the right answer is 16 or 32. It's not the correct answer, strictly speaking, but it is the right one.
An 'int' is also 64 bits on some platforms.
Re: Laws of Software Engineering
#327Just 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”””
Re: Laws of Software Engineering
#328> 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…
If you done enough premature optimization, you will know it’s usually wasted, detrimental and bad trade
Re: Laws of Software Engineering
#329Don'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…
The “second system effect” page more or less covers this
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.
Re: Laws of Software Engineering
#330SOLID being included immediately makes me have zero expectation of the list being curated by someone with good taste.
The few on this page today who object to SOLID seem likely to me to be functional programmers who have never understood software engineering principles in the first place.
Weird take--SOLID, to me (I work in embedded but have done basically everything), represents a system of design principles that mean well and are probably fine in a heavily OO environment 80% of the time but resoundingly end up prime examples of the pareto principle.