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

421–430 of 554 posts

Re: Laws of Software Engineering

#421

Post by jpollock »

tombert wrote: post #413
xorcist wrote: post #389

Earlier quoted context omitted.

I can fully understand "bickering" about someone sprinkling their favourite data type over a codebase which consistently used a standard data type before. The argument that it might be multithreaded in the futurure does not hold if the rest of the code base clearly was not writen with that in mind. That could even be counter productive, should someone get the misguided idea that it was ready for it. Make a (very) goo…

I don’t expose it at the boundaries, just within functions. With everything outside of the function I take a Map interface in and/or return the Map out. It makes no difference to the outside code.

You are communicating with future readers of the code. The presence of ConcurrentHashMap will lead future engineers into believing the code is threadsafe. This isn't true, and believing it is dangerous.

Re: Laws of Software Engineering

#422

Post by tombert »

jpollock wrote: post #421
tombert wrote: post #413

Earlier quoted context omitted.

I don’t expose it at the boundaries, just within functions. With everything outside of the function I take a Map interface in and/or return the Map out. It makes no difference to the outside code.

You are communicating with future readers of the code. The presence of ConcurrentHashMap will lead future engineers into believing the code is threadsafe. This isn't true, and believing it is dangerous.

No, they'll believe that that specific map is thread safe.

Re: Laws of Software Engineering

#424

Post by jamesfinlayson »

f1shy wrote: post #229
iamflimflam1 wrote: post #151

Earlier quoted context omitted.

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

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.

Maybe I'm wrong but I suspect this might be partly due to the rise of Docker which makes attaching a debugger/profiler harder but also partly due to the existence of products like NewRelic which are like a hands-off version of a debugger and profiler.

I haven't used a debugger much at work for years because it's all Docker (I know it's possible but lots of hoops to jump through, plus my current job has everything in AWS i.e. no local dev).

Re: Laws of Software Engineering

#425

Post by m463 »

WalterBright wrote: post #273
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.)

> 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, w…

Even more fun is pointers, especially when windows / macos were switching from 32-bits to 64-bits (in different ways).

Re: Laws of Software Engineering

#427

Post by m463 »

rapnie wrote: post #113
inetknght wrote: post #80

Earlier quoted context omitted.

> It must not be both a floor polish and a dessert topping. I worked as a janitor for four years near a restaurant, so I know a little bit about floor polishing and dessert toppings. This law might be a little less universal than you think. There are plenty of people who would happily try out floor polish as a dessert topping if they're told it'll get them high.

Borax is an example of a substance that is simultaneously used for skin care, household cleaning, as soldiering flux, and ant killer. But I guess it is a constant with variable effects. Hard to be found in local shops anymore.

reminds me of WD-40 (water displacer formula 40).

not used that often to displace water.

Re: Laws of Software Engineering

#428

Post by m463 »

Aaargh20318 wrote: post #63

I’m missing Curly’s Law: https://blog.codinghorror.com/curlys-law-do-one-thing/ “A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance, and carry a different value from a different domain some other time. It should not mean two things at once. It must not be both a floor polish and a dessert topping. It should mean One Thing, and should mean it all of the time.”

As a computer person, I hated math/physics/science because of the one-letter (greek) variable names.

Of course some of that osmosizes back via lisp and APL.

Re: Laws of Software Engineering

#429

Post by YZF »

dimitrios1 wrote: post #281
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…

Even moreso . I like the Rob Pike restatement of this principle, it really makes it crystal clear: "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." Moreso, in my personal experience, I've seen a few speed hacks cause incorrect behavior on more than one occasion.

This is true but doesn't help.

Parent is talking about building software that is inherently non-performant due to abstractions or architecture with the wrong assumption that it can be optimized later if needed.

The analogy is trying to convert a garbage truck into a race car. A race car is built as a race car. You don't start building a garbage truck and then optimize it on the race course. There are obvious principles and understanding that first go into the building of a race car, assuming one is needed, and the optimization happens from that basis in testing on and off the track.

Re: Laws of Software Engineering

#430

Post by regular_trash »

traderj0e wrote: post #415
AtNightWeCode wrote: post #337

Earlier quoted context omitted.

It is misused if anything. YAGNI is about functionality. What to add or not. But it has become an excuse for being lazy. Same people that interpreted the line “Working software over comprehensive documentation” as no need for documentation.

YAGNI is usually about modularization, often in response to Java-style OOP obsession. Like you don't need to define some big protocol that's only ever going to have one implementation.

Well this is not the context I had in mind. I'm thinking of the many times I've had to break apart 3kloc react components to reuse some part just because someone decided modularity didn't matter
Post reply on HN