Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Laws of Software Engineering

lawsofsoftwareengineering.com

Post reply on HN
Print view View original

371–380 of 554 posts

Re: Laws of Software Engineering

#371

Post by computerdork »

dataviz1000 wrote: post #5

I did not see Boyd’s Law of Iteration [0] "In analyzing complexity, fast iteration almost always produces better results than in-depth analysis." Boyd invented the OODA loop. [0] https://blog.codinghorror.com/boyds-law-of-iteration/

That is a good one, iterative development is in general superior to overly deliberate and overly careful development.

And what a great and very subtle example with the fighter jet control sticks. This reminds of a build time issue I once had. Yeah, way back in college, did really poorly on a final programming project, because didn't realize you were supposed to swap out a component they had you write with a mock component that was provided for you - hard to explain, but they wanted you to write this component to show you could, but once you did, you weren't supposed to use it, because it was extremely slow to build. So they also gave you a mock version to use when working on the code of your main system.

Using my full component killed my build time, as it took 10 minutes to build instead of a few seconds, and it was the one school programming project I couldn't finish before the deadline and was super stressful. Was a very painful lesson but ever since have always found ways to shorten my build times.

Re: Laws of Software Engineering

#373

Post by austin-cheney »

giancarlostoro wrote: post #319
austin-cheney wrote: post #146

Earlier quoted context omitted.

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its nece…

> except for those 10% of situations where you know in advance that crucial performance is absolutely necessary Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;)

Those 10% situations will be identified by the business requirements. Everything else is an unmeasured assumption of priorities in conflict with the stated priorities. For the remaining 90% of situations high performance is always important but not as important as working software.

Re: Laws of Software Engineering

#374

Post by zaphar »

ryandrake wrote: post #367
zaphar wrote: post #295

Earlier quoted context omitted.

I probably use a different interpretation of Postel's law. I try not "break" for anything I might receive, where break means "crash, silently corrupt data, so on". But that just means that I return an error to the sender usually. Is this what Postel meant? I have no idea.

Yea, I interpret it as the same thing: On invalid input, don't crash or give the caller a root shell or whatever, but definitely don't swallow it silently. If the input is malformed, it should error and stop. NOT try to read the user's mind and conjure up some kind of "expected" output.

I think perhaps a better wording of the law would be: "Be prepared to be sent almost anything. But be specific about what you will send yourself".

Re: Laws of Software Engineering

#375

Post by mday27 »

conartist6 wrote: post #13

Remember that these "laws" contain so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. The hard part is knowing which law break when, and why

Seems to me like there's also a divide between observational laws (e.g. Hyrum's Law just says "this seems to be true") and prescriptive laws (e.g. Knuth's Law, which is really a statement about how you ought to behave)

Re: Laws of Software Engineering

#376

Post by alsetmusic »

Their statement of Dunning-Kruger is overly simplified such as to misdefine it:

> The less you know about something, the more confident you tend to be.

From the first line on the wiki article:

> systematic tendency of people with low ability in a specific area to give overly positive assessments of this ability.

Or, said another way, the more you know about something the more complexities you're aware of and the better assessment you can make about topics involving such. At least, that's how I understand it in a nutshell without explaining the experiments run and the observations that led to the findings.

Re: Laws of Software Engineering

#377

Post by Jensson »

pydry wrote: post #283
Sammi wrote: post #149

Earlier quoted context omitted.

The problem is that that this term gets misused to say the opposite of what it was intended for. It's particularly the kind of people who like to say "hur hur don't prematurely optimize" that don't bother writing decent software to begin with and use the term as an excuse to write poor performing code. Instead of optimizing their code, these people end up making excuses so they can pessimize it instead.

In my career Ive seen about 1000 instances of somebody trying to optimize something prematurely. Usually those people also have a good old whinge about the premature optimization quote being wrong or misinterpreted and general attitudes to software efficiency. Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

> Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

Many things need to be optimized before you can easily profile them, so at this stage its already too late and your software will forever be slow.

Re: Laws of Software Engineering

#378

Post by toolslive »

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"

Re: Laws of Software Engineering

#379

Post by ryanshrott »

People use the premature optimization principle in exactly the wrong way these days. Knuth's full quote is, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." That 97%/3% split is the whole point.

People bring it up to argue for never thinking about performance, which flips the intent on its head. The real takeaway is that you need to spot that critical 3% early enough to build around it, and that means doing some optimization thinking up front, not none at all.

Re: Laws of Software Engineering

#380

Post by i_am_a_peasant »

afpx wrote: post #254
f1shy wrote: post #229

Earlier quoted context omitted.

It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?” I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is.

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.)

I had one tell me all ints are 16 bits, and then they said 0xffff is a 32bit number.
Post reply on HN