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

471–480 of 554 posts

Re: Laws of Software Engineering

#471

Post by inglor_cz »

jamesfinlayson wrote: post #424
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.

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…

On the other hand, I had to debug a PHP app in Docker using XDebug and it was mostly painless. Or, to be more precise, no more painful than debugging it on local Wamp/Xampp.

Re: Laws of Software Engineering

#472

Post by benrutter »

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…

> Today, late optimization is just as bad as premature optimization, if not more so.

I agree but I don't think this discredits the "premature optimisation is the root of all evil" thing, aside from the fact that it's a heavy exaggeration.

The trouble is, people read it as "don't optimise" which is an incredibly bad decision.

Especially in the data world though, I've seen lots of teams really struggle with problems caused by using technologies they don't need (normally spark or kubernetes or both) just because they might need them later.

I think that type of pitfall is what the original quote is warning against.

Re: Laws of Software Engineering

#473

Post by clauderx »

Ah yes my favorite - Conway's Law is just a fancy way of saying "your architecture is whatever your political mess of a org chart accidentally produced, and everyone calls it 'design' afterward to avoid fixing it."

Re: Laws of Software Engineering

#476

Post by martinclayton »

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/

This resonates with "the bitter lesson" somehow, interesting...

...On reading more it seems of use primarily in adversarial situations, so not-so-much resonant.

Re: Laws of Software Engineering

#477

Post by boonzeet »

tombert wrote: post #335
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…

The biggest issue I have with premature optimization is stuff that really doesn't matter . For example, in Java I usually use ConcurrentHashMap, even in contexts that a regular HashMap might be ok. My reasoning for this is simple: I might want to use it in a multithreaded context eventually and the performance differences really aren't that much for most things; uncontested locks in Java are nearly free. I've gotten…

Ironically to your point, I think adding a ConcurrentHashMap because it might be multithreaded eventually IS premature optimisation.

The work can be done in future to migrate to using ConcurrentHashMap when the feature to add multithreading support is added. There's no sense to add groundwork for unplanned, unimplemented features - that is premature optimisation in a nutshell.

Re: Laws of Software Engineering

#478

Post by gf000 »

materielle wrote: post #441
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.

It’s because in most enterprise contexts: 1) Most bugs are integration bugs. Whereby multiple systems are glued together but there’s something about the API contract that the various developers in each system don’t understand. 2) Most performance issues are architectural. Unnecessary round trips, doing work synchronously, fetching too much data. Debuggers and profilers don’t really help with those problems. I persona…

Doesn't really change the picture. If you don't know the basics of a car, then you absolutely shouldn't be driving in traffic either.

Re: Laws of Software Engineering

#479

Post by firemelt »

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…

lol I never seen it that way

its my favorit quotes

premature optimization nowadays looks like choosing microservice when monolith can works just fine

Re: Laws of Software Engineering

#480

Post by gf000 »

switchbak wrote: post #291
WalterBright wrote: post #273

Earlier quoted context omitted.

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

It's substantially worse on the JVM. One's intuition from C just fails when you have to think about references vs primitives, and the overhead of those (with or without compressed OOPs). I've met very few folks who understand the overheads involved, and how extreme the benefits can be from avoiding those.

In what way is it worse? The range of values they can contain is well-specified.

And you have a frame with an operands stack where you should be able to store at least a 32-bit value. `double` would just fill 2 adjacent slots.

And references are just pointers (possibly not using the whole of the value as an address, but as flags for e.g. the GC) pointing to objects, whose internal structure is implementation detail, but usually having a header and the fields (that can again be reference types).

Pretty standard stuff, heap allocating stuff is pretty common in C as well.

And unlike C, it will run the exact same way on every platform.

Post reply on HN