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

451–460 of 554 posts

Re: Laws of Software Engineering

#451

Post by rustystump »

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…

I have worked on projects that had 5 layers of buffer/caching all implementing complicated evictions strategies. This is all a browser client. There were 4 caching layers when i started. I added the 5th caching freq network data to disk which massively improved performance.

This is too true. However, often you dont fully know the shape of the domain until you swing at it and fail.

Re: Laws of Software Engineering

#452

Post by ludston »

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…

If you don't have personal examples of using a profiler to diagnose an issue like "too many round trips" and identify where those round trips are coming from, then you've never inherited a complex performance problem before.

Re: Laws of Software Engineering

#453

Post by rustystump »

iamflimflam1 wrote: post #151
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…

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

Language conventions aside, i have rarely found a comments to be and more often they have lied to me. AI makes this both worse and better.

I know it may be hard for me to understand the need for writing in english what is obvious (to me) in code. I also know i have read a stupid amount of code.

My rule is simple, if the comment repeats verbatim the name of a variable declaration or function name, it has to go. Anything else we can talk about.

Re: Laws of Software Engineering

#454

Post by rustystump »

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…

That is surprising. They have come up in every enterprise job i have had. Debuggers and profilers absolutely do help although for distributed systems they are called something else.

Re: Laws of Software Engineering

#455

Post by rustystump »

didgetmaster wrote: post #358
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.

I once interviewed at Microsoft. The hiring manager asked me how I would go about programming a break point if I were writing a debugger. I started to explain how I would have to swap out an instruction to put an INT 3 in the code and then replace it when the breakpoint would hit. He stopped me an said he was just looking to see if I knew what an INT 3 was. He said few engineers he interviewed had any idea.

What is an int3

Re: Laws of Software Engineering

#456

Post by AdieuToLogic »

m463 wrote: post #425
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…

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

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

And yet even more of a fun time with porting pointer code was going from the various x86 memory models[0] to 32-bit. Depending on the program, the pain was either near, far, or huge... :-D

0 - https://en.wikipedia.org/wiki/X86_memory_models

Re: Laws of Software Engineering

#457

Post by buu700 »

physicles wrote: post #272
jimmypk wrote: post #64

Earlier quoted context omitted.

[flagged]

I’m one of those that have thrown out Postel’s law entirely. Maybe the issue is that it never defines “strict”, “liberal”, and “accept”. But at least for public APIs, it never made sense to me. If I accidentally accept bad input and later want to fix that, I could break long-time API users and cause a lot of human suffering. If my input parsing is too strict, someone who wants more liberal parsing will complain, and…

I've always liked Postel's law as a general philosophy toward life. But yeah, it's definitely become a little dated in the software world, if it was ever a good idea at all.

Re: Laws of Software Engineering

#459

Post by computerdork »

AnimalMuppet wrote: post #436
computerdork wrote: post #371

Earlier quoted context omitted.

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

> iterative development is in general superior to overly deliberate and overly careful development. I reserve the right to become smarter as I learn stuff. That means that I reserve the right to produce better designs as I learn stuff. Want me to produce better designs? Let me learn stuff . Therefore, let me iterate a few times.

agreed:)
Post reply on HN