HN Explorer

Ask HN: What Are the Laws of Software?

10 points by minzi ↗ HN
I was reading the article "A Few Rules" that was posted yesterday and Housel brings up the idea that most fields only have a few laws. This idea in the context of another recently posted article titled "People expect technology to suck because it actually sucks" have me wondering whether some core laws might be beneficial to software engineering. Sorry if the question is naive. I am only an undergraduate and I study more math than cs.

14 comments

[ 3.2 ms ] story [ 43.5 ms ] thread
AnimalMuppet
The most general problem cannot be solved.
kleer001
Oh, I think you just stated P vs NP in plain English. Excellent!
AnimalMuppet
No, it's much wider than that. Your OS cannot be optimally tuned for all uses. Your DB cannot be optimally tuned for all queries. Your language cannot be the best language for all use cases.

And that's before we talk about cross uses. Your web browser can't also be a good IDE. Your DB can't also be a good general-purpose OS. And so on.

kleer001
It's almost like managing information requires trade offs.
shoo
but some freeing counterpoints are: you almost never need to solve the most general problem -- instead solve the restricted problem you actually have, not the general problem you want to have; it's better to roughly solve an accurate statement of the problem rather than exactly solve an inaccurate statement of the problem.
greenyoda
How do you define "law"? Do you mean statements about the fundamental nature of physical reality, like the laws of motion or the laws of thermodynamics, or do you also include rules of thumb like Moore's Law?
ericb
The book "The Mythical Man-Month" has some of those laws built in.
brudgers
The Mythical Man-Month is not a silver bullet.
jessehorne
I'll give it a go. Here's some "commandments" I just came up with.

1. Thou shalt not skip out on proper documentation, otherwise you and your comrades will suffer the consequences within time.

2. Thou shalt use appropriate standards developed by yourself, your team and the community surrounding your tools.

3. Thou shalt take breaks

4. Thou shalt understand the problem in full before approaching a solution

5. Thou shalt value the time of yourself and your users

I could keep going...

scott31
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

kazinator
Software that is maintained only increases in size until it is no completely unusable on the original hardware. Each successive update leaves less flash space and RAM for the user's payload.