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

341–350 of 554 posts

Re: Laws of Software Engineering

#341

Post by fragmede »

estimator7292 wrote: post #304
afpx wrote: post #254

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

It's the wrong question. How many bits is uint64 is a much better question, if we're at a place where that's relevant.

Re: Laws of Software Engineering

#343

Post by kgwxd »

GuB-42 wrote: post #138

> 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…

All aphorisms are awful.

Re: Laws of Software Engineering

#346

Post by SAI_Peregrinus »

ghosty141 wrote: post #276
paulddraper wrote: post #269

Earlier quoted context omitted.

It causes excessive abstraction, and more verbose code. L and I are both pretty reasonable. But S and D can easily be taken to excess. And O seems to suggest OO-style polymorphism instead of ADTs.

This is similar to my view. All these "laws" should alwaye be used as guidance not as actual laws. Same with O. I think its good advice to design software so adding features that are orthogonal to other features don't require modifying much code. That's how I view it. You should design your application such that extension involves little modifying of existing code as long as it's not necessary from a behavior or arch…

Of course you can do that & still make a mess. E.g. by deciding that all your behavior will be "configurable" by coding inside strings in a YAML file, and what YAML files you load at runtime determine which features you get. Sure, they might conflict, but that's the fault of whoever wrote that "configuration" YAML. (Replace YAML with XML for a previous era version of this bad idea).

Re: Laws of Software Engineering

#347

Post by tmoertel »

someguyiguess wrote: post #191
tmoertel wrote: post #7

One that is missing is Ousterhout’s rule for decomposing complexity: complexity(system) = sum(complexity(component) * time_spent_working_in(component) for component in system). The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.

Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

> Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

No, it’s a win, even then.

Say you are writing an operating system, and one of the fundamental data structures you use all over the place is a concurrency-safe linked list.

Option 1 is to manipulate the relevant instances of the linked list directly—whenever you need to insert, append, iterate over, or delete from any list from any subsystem in your operating system. So you’ll have low-level list-related lock and pointer operations spread throughout the entire code base. Each one of these operations requires you to struggle with the list at the abstraction level and at the implementation level.

Option 2 is to factor out the linked-list operations and isolate them in a small library. Yes, you must still struggle with the list at the abstraction and implementation levels in this one small library, but everywhere else the complexity has been reduced to having to struggle with the abstraction level only, and the abstraction is a small set of straightforward operations that is easy to wrap your head around.

The sole difference between the options, as you wrote, is that “the complexity just migrates to another location.” But which would you rather maintain?

That was Ousterout’s point.

Re: Laws of Software Engineering

#348

Post by asdfman123 »

> Leave the code better than you found it

In most places, people don't follow this rule, as it ensures either you're working an extra 10-20 hours a week to keep things clean, or stuck at mid-level for not making enough impact.

I choose the second option. But I see people who utterly trash the codebase get ahead.

Re: Laws of Software Engineering

#349

Post by wombatpm »

Sharlin wrote: post #340
alexjplant wrote: post #313

Earlier quoted context omitted.

> "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary beca…

You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance"

At a minimum they should comment their GOTO’s

Re: Laws of Software Engineering

#350

Post by jimbokun »

astrobe_ wrote: post #275
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

This reminds me of a comment I read here a long time ago; it was about XML and how DTDs were supposed to permit one to be strict. However, in reality, the person said, if the the other end who is sending you broken XML is a big corp who refuses to fix it, then you have no choice but accept it. Bottom line: it's all a matter of balance of powers. If you're the smaller guy in the equation, you'll be "Postel'ed" anyway.…

Would be tempted to stick a proxy in there that checks if the data is malformed in the expected way, and if so converts it to the valid form before forwarding to the real service.
Post reply on HN