4 ms·
Ask HN: What Are the Laws of Software?
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.
- smoyer 6y agoIf this isn't the canonical source, then improve the list by submitting issues and/or pull-requests! - https://github.com/dwmkerr/hacker-laws https://github.com/dwmkerr/hacker-laws
- AnimalMuppet 6y agoThe most general problem cannot be solved.
- kleer001 6y agoOh, I think you just stated P vs NP in plain English. Excellent!
- AnimalMuppet 6y agoNo, 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 6y agoIt's almost like managing information requires trade offs.
- shoo 6y agobut 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 6y agoHow 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 6y agoThe book "The Mythical Man-Month" has some of those laws built in.
- brudgers 6y agoThe Mythical Man-Month is not a silver bullet.
- atsaloli 6y ago“The Primary Law of Software Design” is relevant here. https://www.codesimplicity.com/post/the-primary-law-of-software-design/ https://www.codesimplicity.com/post/the-primary-law-of-softw...
- brudgers 6y agoProgramming has Epigrams: https://cpsc.yale.edu/epigrams-programming https://cpsc.yale.edu/epigrams-programming
- jessehorne 6y agoI'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 6y agoRule 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 6y agoSoftware 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.