[dead]

>Performance isn’t a luxury—it’s foundational.

Reasons to always try to be nearly optimal on performance from the start, that I rarely saw stated:

1) What you can specify depends on what can be done, and to know what can be done you need to have tried your best. In particular, it allows to see early whether or not performance expectations are reallistic.

2) It's more difficult or impossible to upgrade performance later if it requires to break an API. It causes a development process in O(n^2) in number of layers, instead of O(n).

3) Better lower level performance makes higher level code and architecture simpler, as you can just brute force in more places for a same overall performance.

▲

blitzar 7 months ago | parent | next [-]

No offence intended, however, this is literally the pitch I have seen for why startups with 5 users need to architect their product to be global scale for 1 billion concurrent users. (those that try always burn out and fail)

	▲	JohnBooty 7 months ago \| parent [-]
		In reality, I feel like this tends to translate to "we need to scale horizontally and make sure our code runs on a large number of machines" with little consideration for actually optimizing the code itself. In fact, devoting time to code optimization tends to be explicitly discouraged in my experience. The prevailing wisdom seems to be, "write shitty code... just make sure it runs on as many AWS machine instances as possible."

▲

fredtalty5 7 months ago | parent | prev [-]

[dead]

▲

jasfi 7 months ago | parent | prev | next [-]

New products or features are of an acceptable performance only, sometimes not even that. Additional work on performance tuning is often followed up in a later version. It's really about priorities that have to be decided, and deadlines usually win.

Those that prioritize performance upfront can find all that work thrown out if the design needs to change for some reason.

But I think that performance by design upfront should be done where possible. This is where experience helps a ton.

▲

blitzar 7 months ago | parent [-]

Allowing (encouraging even) the paying down of technical debt is the real solution. Build the prototypes fast and broken, if they catch on then fix them. This was the way things were once done, and how most of the billions were originally made.

▲

jasfi 7 months ago | parent [-]

Not too broken, or you waste a lot of time fixing bugs. Rather build prototypes minimally but working well.

	▲	blitzar 7 months ago \| parent [-]
		The challenge is convincing management that a 200 person-hour prototype that looks good and "works" needs another 1000+ person hours to button up - or take the promotion, hop to the competition and then it is not-your-problem ...

▲

top256 7 months ago | parent | prev [-]

I agree and I think there's a market for faster computers!