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

461–470 of 554 posts

Re: Laws of Software Engineering

#461

Post by materielle »

davedx wrote: post #202
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, performance is mostly about architectural choices, and it has to be given consideration right from the start" This doesn't make sense. Why is performance (via architectural choices) more important today than then? You can build a snappy app today by using boring technology and following some sensible best practices. You have to work pretty hard to need PREMATURE OPTIMIZATION on a project -- note the premature…

Because you can naively iterate through a million items faster than an additional network round trip would take.

So a lot of code quality debates don’t matter for the typical enterprise app. While a dev spends their afternoon shaving off 100 nanoseconds in the hot path, a second developer on a deadline added a poorly thought out round trip that adds 800milliseconds.

This architectural problems are also more difficult to unwind later since they tend to have cascading effects.

Re: Laws of Software Engineering

#462

Post by lock1 »

rustystump wrote: post #455
didgetmaster wrote: post #358

Earlier quoted context omitted.

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

CPU interrupt for breakpoint, https://wiki.osdev.org/Interrupt_Vector_Table

Re: Laws of Software Engineering

#463

Post by wredcoll »

YZF wrote: post #431
pydry wrote: post #283

Earlier quoted context omitted.

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.

In my career I've seen endless examples of hopelessly badly designed software where no amount of optimization can turn it into anything other than a piece of garbage. Slow, bloated and inefficient. Ascertain an issue is too late for bad software. The technical term is polishing a turd. Not that what you're describing doesn't happen, people trying to make something irrelevant fast, but that's not the big problem we fa…

Hurray, bad software is bad, we did it! Just don't write bad code!

Re: Laws of Software Engineering

#464

Post by YZF »

wredcoll wrote: post #463
YZF wrote: post #431

Earlier quoted context omitted.

In my career I've seen endless examples of hopelessly badly designed software where no amount of optimization can turn it into anything other than a piece of garbage. Slow, bloated and inefficient. Ascertain an issue is too late for bad software. The technical term is polishing a turd. Not that what you're describing doesn't happen, people trying to make something irrelevant fast, but that's not the big problem we fa…

Hurray, bad software is bad, we did it! Just don't write bad code!

Before you write code you design (and/or architect) a system (formally or informally).

There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

Re: Laws of Software Engineering

#465

Post by wredcoll »

hunterpayne wrote: post #400
pydry wrote: post #283

Earlier quoted context omitted.

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." That's because your boss will never in a 1000 years hire the type of dev who can do that. And even if you did, there will be team members who will fight those fixes tooth and nail. And yes, I have a very cynical view of some devs but they earned that through some of th…

Man, what are you talking about? Speed optimizations after shipping software happens constantly in everything from video games in C to ui libraries in js and everything in between.

People write some code, test it, ship it, then get some ideas that its too slow and make it faster.

The nice thing about doing it with shipped code is you can actually measure where time is spent insyead of guessing.

Re: Laws of Software Engineering

#466

Post by wredcoll »

YZF wrote: post #464
wredcoll wrote: post #463

Earlier quoted context omitted.

Hurray, bad software is bad, we did it! Just don't write bad code!

Before you write code you design (and/or architect) a system (formally or informally). There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.

Re: Laws of Software Engineering

#467

Post by brabel »

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…

I think you are in the wrong. But my reason is that when you support concurrency, every access and modification must be checked more carefully. By using a concurrent Map you are making me review the code as if it must support concurrency which is much harder. So I say don’t signal you want to support concurrency if you don’t need it.

Re: Laws of Software Engineering

#468

Post by WalterBright »

LPisGood wrote: post #450
WalterBright wrote: post #443

Earlier quoted context omitted.

C is a portable language, in that programs will likely compile successfully on a different architecture. Unfortunately, that doesn't mean they will run properly, as the semantics are not portable.

So what’s the point of having portable syntax, but not portable semantics?

C certainly gives the illusion of portability. I recall a fellow who worked on DSP programming, where chars and shorts and ints and longs were all 32 bits. He said C was great because that would compile.

I suggested to him that he'd have a hard time finding any existing C code that ran correctly on it. After all, how are you going to write a byte to memory if you've only got 32 bit operations?

Anyhow, after 20 years of programming C, I took what I learned and applied it to D. The integral types are specified sizes, and 2's complement.

One might ask, what about 16 bit machines? Instead of trying to define how this would work in official D, I suggested a variant of D where the language rules were adapted to 16 bits. This is not objectively worse than what C does, and it works fine, and the advantage is there is no false pretense of portability.

Re: Laws of Software Engineering

#469

Post by KnuthIsGod »

awesome_dude wrote: post #410
switchbak wrote: post #291

Earlier quoted context omitted.

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.

My favourite JVM trivia, although I openly admit I don't know if it's still true, is the fact that the size of a boolean is not defined. If you ask a typical grad the size of a bool they will inevitably say one bit, but, CPUs and RAM, etc don't work like that, typically they expect WORD sized chunks of memory - meaning that the boolean size of one but becomes a WORD sized chunk, assuming that it hasn't been packed

". While it represents one bit of information, it is typically implemented as 1 byte in arrays, and often 4 bytes (an int) or more as a standalone variable on the stack "

Re: Laws of Software Engineering

#470

Post by wavemode »

GuB-42 wrote: post #217
ghosty141 wrote: post #167

Earlier quoted context omitted.

What's the problem with SOLID? It's very very rare that I see a case where going against SOLID leads to better design.

SOLID tend to encourage premature abstraction, which is a root of evil that is more relevant today than optimization. SOLID isn't bad, but like the idea of premature optimization, it can easily lead you into the wrong direction. You know how people make fun of enterprise code all the time, that's what you get when you take SOLID too far. In practice, it tends to lead to a proliferation of interfaces, which is not onl…

A lot of people make the mistake of thinking that if you just follow SOLID then you have good code, but plenty of teams follow it to the letter and still create complete messes.

The problem is that SOLID on its own does nothing for you. It's a set of (vague) rules, but not a full framework for how to design software. I would even argue that SOLID is actively harmful if used on its own.

Things like Clean Architecture and Domain-Driven Design are a lot closer to being true frameworks for software design, and a lot of their basic principles are actually really good (like the core of the application being made up of objects which perform calculations, validations and business rules with no side effects), but the complexity of those architectures is a problem in itself.

And, even aside from that, I think the industry in general reached a point where people decided that, principled object-oriented design is just not worth it. Why spend all this effort worrying about the software remaining maintainable for decades, when we could instead just throw together something that works, then IPO, then rewrite the whole thing once we have money.

Post reply on HN