Hacker News Reader

Comment by cr0sh | Hacker News Reader

How I've always put it:

"Steak before sizzle"

Get something done and working, even if performance sucks. Then do your performance logging and optimizations. Don't attempt to pre-optimize, because you may make a good situation worse.

That doesn't preclude selecting correct algorithms and such beforehand; ie - don't be stupid about it. But don't try to be clever before you know you need it, either.

Second thing I always think should be necessary for any software project:

Get your security design working first.

Don't try to patch in security after the fact; if this isn't at the top of your design and planning, it should be (assuming the project needs it or can be foreseen to need it). Too often I have witnessed the opposite - and it almost never works without major refactoring (or scrapping and starting over).

View on HN

> "Steak before sizzle"

I like it!

> That doesn't preclude selecting correct algorithms and such beforehand; ie - don't be stupid about it. But don't try to be clever before you know you need it, either.

Exactly. "Avoid premature optimisation" doesn't mean "make it as slow as possible", it just means "use std::vector until it becomes an issue instead of hand-coding some arcane data structure in assembler".

I would personally expand it to this: Steak before sizzle, but don't get everyone sick by serving it raw...

Except that salespeople say "don't sell the steak, sell the sizzle!", so this could get confusing.

Isn't that the point, though? You sell the sizzle... but you can't deliver without the steak.

Actually, this is now possible, as Kubernetes makes it easy to deploy steakless applications. I think i heard that.

From an operations perspective, there are three critical things:

Security, Durability, Availability.

From my perspective, that's the order of importance too, but any one without the other two and you're not going to gain or retain customers.

Your order also captures permanence. If another actor gains access to the data, I cant revoke it. If I lose the data, I cant access it. If I cant access the data now, I can try again later.

On your second point ... Im not sure. Sony is still in business. Equifax and co are still printing money. OPM is still around. Security and trust doesnt seem so binary in practice.

>Get your security design working first.

Tbe ahove applies to accessibility too, by the same reasoning.

> Get something done and working, even if performance sucks.

Often if "performance sucks" then it isn't done and isn't working. Performance is a client requirement like any other.

True, but when writing a 2D card game, aiming for an engine capable of doing 3D VR at 120fps is probably a bit too much.

Yet it is what I sometimes see when this performance discussions take place.

Reply on news.ycombinator.com