Great! Do principles fit? If so, considering presence of "Bus Factor", I believe "Chesterton's Fence" should be listed, too.
Laws of Software Engineering
31–40 of 554 posts
Re: Laws of Software Engineering
#32Earlier quoted context omitted.
DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.
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.
Re: Laws of Software Engineering
#33Not 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.
What's the smallest unit of functionality to which your principle applies?
For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?
Re: Laws of Software Engineering
#34Earlier 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.
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.
Re: Laws of Software Engineering
#35> Get it working correctly first, then make it fast, then make it pretty. Or develop a skill to make it correct, fast and pretty in one or two approaches.
I recently had success with a problem I was having by basically doing the following: - Write a correct, pretty implementation - Beat Claude Code with a stick for 20 minutes until it generated a fragile, unmaintainable mess that still happened to produce the same result but in 300ms rather than 2500ms. (In this step, explicitly prompting it to test rather than just philosophising gets you really far) - Pull across the…
However, a correct, pretty and fast solution may exist that neither of you have found yet.
But yes, the scope and breadth of their knowledge goes far beyond what a human brain can handle. How many relevant facts can you hold in your mind when solving a problem? 5? 12? An LLM can take thousands of relevant facts into account at the same time, and that's their superhuman ability.
Re: Laws of Software Engineering
#36It's missing: > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Shouldn't it also be able to read email? I think that was a law too.
Anyway, the list seems like something AI scraped and has a strong bias towards "gotcha" comments from the likes of reddit.
Re: Laws of Software Engineering
#37Pure gold :) I'm missing one though; "You can never underestimate an end user.".
Re: Laws of Software Engineering
#38On my laptop I have a yin-yang with DRY and YAGNI replacing the dots.
Re: Laws of Software Engineering
#39> Get it working correctly first, then make it fast, then make it pretty. Or develop a skill to make it correct, fast and pretty in one or two approaches.
Modern SaaS: make it "pretty", then make it work, then make it "pretty" again in the next release. Make fast? Never.
Re: Laws of Software Engineering
#40Earlier quoted context omitted.
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.
First, few of the laws on that site are actual laws in the physics or mathematics sense. They are more guiding principles. > complexity is not a function of time spent working on something. But the complexity you observe is a function of your exposure to that complexity. The notion of complexity exists to quantify the degree of struggle required to achieve some end. Ousterhout’s observation is that if you can move co…
And in addition, the time you spend making a component work properly is absolutely a function of its complexity. Once you get it right, package it up neatly with a clean interface and a nice box, and leave it alone. Where "getting it right" means getting it to a state where you can "leave it alone".