12 ms·

Its comments like this that make people hate HN. I agree with their writeup fully. They focused wayyyy too much on performance and not enough on an MVP, pivotin

Its comments like this that make people hate HN. I agree with their writeup fully. They focused wayyyy too much on performance and not enough on an MVP, pivoting, marketing, growth, and staying agile. I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Hell, give em three weeks and they still wouldn't have a single line of code written. But they would still be arguing about the best way to deal with their upcoming 1 million hits per second. Rule #1 of any business: Sales cures all. You know what's really hard to sell? A product that hasn't even made it out of the damn door yet.

juangacovas 8y ago
Well, as someone else said, it's not always black or white. Videogames MUST deliver performance, it's not only sales. Some desktop AND web applications could benefit from some performance boost here and there, and I mean being fast enough and not some abominations I've seen/heard about (minutes to get Excel files and examples like that, just because they're "thousands" of rows from a database). You know, sales is everything and I agree that "there are two types of software: software that people complain about and software that nobody talks about", but some of us take some pride on doing stuff with enough performance and not pure crap...
- CJefferson 8y ago
  Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great. Mist was mostly a series of static images. They are two of the best selling games of all time.
  - aspencer8111 8y ago
    Yep...100x this! What is that they say about pride and what it cometh before??? Take as much pride as you want. Just remember to, you know, ship something from time to time.
  - avinium 8y ago
    > Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great Perfect example. You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I see this time and time again - beautifully architected and performant platforms that completely bomb because noone actually wants it.
    - CodeMage 8y ago
      > You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I agree with that. And yet, Minecraft is possibly the worst example: - It's an exception to the general wisdom that games do have to worry about performance in order to deliver fun. Just because Minecraft became popular despite it's abysmal performance, doesn't mean games can get away with that in general. - Notch never expected Minecraft to become that popular. In a sense, Minecraft was an accident. - Minecraft's performance was so bad, a lot of people had to install a mod called OptiFine just to be able to play it on their hardware.
      - avinium 8y ago
        Oh, I do think performance matters - but that's usually only once you've discovered your underlying market. Minecraft's audience clearly didn't care about performance, so it would have been wasted effort to optimize in the early days. That being said, I agree that performance might actually be integral to your product. Quake 3, for example, probably would have bombed if everyone was playing sub-10fps. Either way, the priority is "figure out who wants your product and why." That helps determine when and where to focus your optimization efforts.
  - juangacovas 8y ago
    Guessing Minecraft has enough performance to be playable. Wolfenstein 3D? Doom? Pretty good performance anyone? World of Warcraft being playable on low end PCs? Come on... Not everything is black or white.
  - p1necone 8y ago
    People say that, but it still runs playably on pretty ancient hardware, it's certainly easier to get running that most AAA titles.
  - munificent 8y ago
    > Myst was mostly a series of static images. Myst was at the cutting edge of technology at the time. They had to write some weird custom extensions in order to jam color into HyperCard at all. (Myst was initially written in HyperCard!) One could argue that designing the game around static images that could be rendered offline was itself an optimization. It gave the illusion of an immersive 3D space within the very harsh limitations of early Macs. Also, the couple of QuickTime videos used in the game were very carefully integrated into a surrounding static image to give the illusion of an entire live scene while only animating a small rectangle of it because that's all most computers could handle at the time. Myst is a fantastic example of making very thoughtful performance decisions given the constraints at the time.
  - reificator 8y ago
    Myst is not the example you think it is. It's a fully 3D world with moving parts like the library staircase or the redwoods or the train section. That they managed to pull it off for home computers in 1993 is nothing short of a performance focused mindset which led them to static images and QuickTime overlays. As soon as they had the ability, they released realMyst which was a realtime 3D version of the original, followed by realMyst Masterpiece in the last 5-10 years. For that matter, Minecraft may be poorly optimized (it is) but without the effort spent on the chunking system that renders 16x16x(128/256) blocks as a single mesh, it wouldn't run at all. There's plenty of low hanging fruit (which may be more difficult to retrofit into the existing engine, or in the JVM itself) that other games have found and utilized, but without that initial performance optimization Minecraft wouldn't run at all.
- munchbunny 8y ago
  Videogames MUST deliver performance That's not true in the way that I think you're using video games as an example. Video games must be fun, being fun requires being performant enough, and for graphically demanding games that requires lots of optimizing. But there are tons of games that are not graphically demanding.
- spyhi 8y ago
  Ehhh, I don't think your example disproves the idea you're responding to. Perhaps video games MUST deliver performance in the end, but often game prototypes are not performant at all for the sake of rapid experimentation, and are only optimized towards the end of development once all the systems are set in stone...which is what's being advocated for here.
  - PakG1 8y ago
    In the old days, customers would never be able to get their hands on video game prototypes. You had one shot. Today, it's obviously a bit different, though many companies still treat it like one shot anyway.
    - pjmlp 8y ago
      Sure they would. Game studios were one of the first areas to care for UX. During the 80's and early 90's many kids got into games by starting as group testers after school.
      - PakG1 8y ago
        At that point, they were insiders or even employees, not final customers, no? Games were released onto cartridges that couldn't be updated once the cartridges were manufactured and in the customer's hands.
        pjmlp 8y ago
        Insiders if you will, studios would get the kids into a room to play test ongoing development. It wasn't always the same group of kids.
    - spyhi 8y ago
      Yeah, but even in the old days the developers would still be prototyping. Internal stakeholders are still stakeholders, and it’s developers optimizing for things other than speed. Nintendo devs famously build nothing until Mario’s jump (the MVP) feels right.
- pjmlp 8y ago
  That depends on the game. Writing casual games with AAA tech is needless overengeniring.
CodeMage 8y ago
> I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Except that's not the argument in the comment you're reacting to. Here's what the comment actually said: > Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if road A is taken instead of road B. In other words, some optimizations come with no significant cost. As a banal, perhaps exaggerated example, if you're writing code that needs to store data in a collection and you know that it's going to perform random access to that data on a regular basis, you're not likely to pick a linked list over some kind of array. What @abraae is criticizing is the practice of asserting "best practices" that are likely to be taken out of context, widely propagated and misinterpreted. Knuth's famous assertion "premature optimization is the root of all evil" is an excellent example. People love quoting it, but few seem to take into account the context, to the point that it has been largely forgotten. Here's the quote in its context: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. To be clear, it's not Knuth's fault that people are taking his very rational and sensible advice and reducing it to "yeah, you should totally disregard performance when first writing your code". This is not about pointing fingers and assigning blame, it's about being responsible when offering advice. Knuth's advice was reasonable and nuanced, and it still got taken out of context and reduced to something different and arguably harmful. Now look at Gabriel's advice, which is arguably a lot easier to take out of its context and misinterpret, and imagine the consequences it could have. That is what @abraae is reacting to. EDIT: There's another thing that really, really bothers me about your reply: > Rule #1 of any business: Sales cures all. This, right here, is what I personally feel is wrong with software nowadays. It's how we end up with poorly written, bloated, bug-ridden, unstable, unreliable, insecure crap that we end up using anyway, because there's no better alternative.
- jpochtar 8y ago
  Ironically, Knuth's full argument is exactly what we're saying, and what @abraae's taking out of context to criticize. See https://medium.com/@jaredpochtar/on-performance-and-software-engineering-44eefa90d46f https://medium.com/@jaredpochtar/on-performance-and-software... and the full section on https://medium.com/@gabriel_20625/technical-lessons-from-building-a-compiler-startup-for-3-years-4473405161cd https://medium.com/@gabriel_20625/technical-lessons-from-bui... > Most of the code we wrote was fast enough (<2ms) that making it faster wouldn’t be noticeable, so it would definitely be a waste of time to optimize. Making code that’s 0.1% of your runtime 100x faster only makes your latency <1% lower.
cr0sh 8y ago
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).
- Twirrim 8y ago
  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.
  - donavanm 8y ago
    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.
- taneq 8y ago
  > "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".
  - 8y ago
Aeolun 8y ago
> You know what's really hard to sell? A product that hasn't even made it out of the damn door yet. I don’t know about this. I generally end up building the things that have already been sold.
WhitneyLand 8y ago
Can your comment help anyone? It seems to be within the set of concepts and suggestions that cannot fully sink in and be truly appreciated until some degree of failure or experience relating to them has occurred. Yeah, they read it. they get it. But they still don't get it, if you know what I mean. But wow - this one sure does take on some laser etched permanence once it does get through.
quickthrower2 8y ago
Just apply some common sense and paretos rule. I.e don’t do something dumb because there is no measure. E.g. a loop that needlessly iterates a billion times.
zimpenfish 8y ago
I once had a multi-day argument with the other 2 devs on the team about whether a set of MySQL queries and code would scale to thousands of reporting devices. My stance was that it didn't matter because if we didn't make the TWENTY devices we had work by next week, we'd lose that contract and pretty soon our jobs.
lucideer 8y ago
The commenter you’re replying to isn’t saying “performance first”, they’re just saying “performance matters”. In other words—don’t go to extremes in any direction. It sounds very much like this conpany took an extreme perf-first approach from the outset, and advocate a reactionary overcompensated opposite extreme in their postmortem.
manquer 8y ago
It is not that simple. While premature optimization is definitely a problem, In my experience not handling it correctly before the app is in prod usually results in having to fix logical bugs , refactor for performance and add new features users are clamouring for at the same time. We don't get lot of chances with users to say you will eventually fix these issues for them, you will simply loose them . As all things there has to be a balance between both ends

juangacovas 8y ago

Well, as someone else said, it's not always black or white. Videogames MUST deliver performance, it's not only sales. Some desktop AND web applications could benefit from some performance boost here and there, and I mean being fast enough and not some abominations I've seen/heard about (minutes to get Excel files and examples like that, just because they're "thousands" of rows from a database). You know, sales is everything and I agree that "there are two types of software: software that people complain about and software that nobody talks about", but some of us take some pride on doing stuff with enough performance and not pure crap...

CJefferson 8y ago
Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great. Mist was mostly a series of static images. They are two of the best selling games of all time.
- aspencer8111 8y ago
  Yep...100x this! What is that they say about pride and what it cometh before??? Take as much pride as you want. Just remember to, you know, ship something from time to time.
- avinium 8y ago
  > Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great Perfect example. You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I see this time and time again - beautifully architected and performant platforms that completely bomb because noone actually wants it.
  - CodeMage 8y ago
    > You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I agree with that. And yet, Minecraft is possibly the worst example: - It's an exception to the general wisdom that games do have to worry about performance in order to deliver fun. Just because Minecraft became popular despite it's abysmal performance, doesn't mean games can get away with that in general. - Notch never expected Minecraft to become that popular. In a sense, Minecraft was an accident. - Minecraft's performance was so bad, a lot of people had to install a mod called OptiFine just to be able to play it on their hardware.
    - avinium 8y ago
      Oh, I do think performance matters - but that's usually only once you've discovered your underlying market. Minecraft's audience clearly didn't care about performance, so it would have been wasted effort to optimize in the early days. That being said, I agree that performance might actually be integral to your product. Quake 3, for example, probably would have bombed if everyone was playing sub-10fps. Either way, the priority is "figure out who wants your product and why." That helps determine when and where to focus your optimization efforts.
- juangacovas 8y ago
  Guessing Minecraft has enough performance to be playable. Wolfenstein 3D? Doom? Pretty good performance anyone? World of Warcraft being playable on low end PCs? Come on... Not everything is black or white.
- p1necone 8y ago
  People say that, but it still runs playably on pretty ancient hardware, it's certainly easier to get running that most AAA titles.
- munificent 8y ago
  > Myst was mostly a series of static images. Myst was at the cutting edge of technology at the time. They had to write some weird custom extensions in order to jam color into HyperCard at all. (Myst was initially written in HyperCard!) One could argue that designing the game around static images that could be rendered offline was itself an optimization. It gave the illusion of an immersive 3D space within the very harsh limitations of early Macs. Also, the couple of QuickTime videos used in the game were very carefully integrated into a surrounding static image to give the illusion of an entire live scene while only animating a small rectangle of it because that's all most computers could handle at the time. Myst is a fantastic example of making very thoughtful performance decisions given the constraints at the time.
- reificator 8y ago
  Myst is not the example you think it is. It's a fully 3D world with moving parts like the library staircase or the redwoods or the train section. That they managed to pull it off for home computers in 1993 is nothing short of a performance focused mindset which led them to static images and QuickTime overlays. As soon as they had the ability, they released realMyst which was a realtime 3D version of the original, followed by realMyst Masterpiece in the last 5-10 years. For that matter, Minecraft may be poorly optimized (it is) but without the effort spent on the chunking system that renders 16x16x(128/256) blocks as a single mesh, it wouldn't run at all. There's plenty of low hanging fruit (which may be more difficult to retrofit into the existing engine, or in the JVM itself) that other games have found and utilized, but without that initial performance optimization Minecraft wouldn't run at all.
munchbunny 8y ago
Videogames MUST deliver performance That's not true in the way that I think you're using video games as an example. Video games must be fun, being fun requires being performant enough, and for graphically demanding games that requires lots of optimizing. But there are tons of games that are not graphically demanding.
spyhi 8y ago
Ehhh, I don't think your example disproves the idea you're responding to. Perhaps video games MUST deliver performance in the end, but often game prototypes are not performant at all for the sake of rapid experimentation, and are only optimized towards the end of development once all the systems are set in stone...which is what's being advocated for here.
- PakG1 8y ago
  In the old days, customers would never be able to get their hands on video game prototypes. You had one shot. Today, it's obviously a bit different, though many companies still treat it like one shot anyway.
  - pjmlp 8y ago
    Sure they would. Game studios were one of the first areas to care for UX. During the 80's and early 90's many kids got into games by starting as group testers after school.
    - PakG1 8y ago
      At that point, they were insiders or even employees, not final customers, no? Games were released onto cartridges that couldn't be updated once the cartridges were manufactured and in the customer's hands.
      - pjmlp 8y ago
        Insiders if you will, studios would get the kids into a room to play test ongoing development. It wasn't always the same group of kids.
  - spyhi 8y ago
    Yeah, but even in the old days the developers would still be prototyping. Internal stakeholders are still stakeholders, and it’s developers optimizing for things other than speed. Nintendo devs famously build nothing until Mario’s jump (the MVP) feels right.
pjmlp 8y ago
That depends on the game. Writing casual games with AAA tech is needless overengeniring.

CodeMage 8y ago

> I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Except that's not the argument in the comment you're reacting to. Here's what the comment actually said: > Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if road A is taken instead of road B. In other words, some optimizations come with no significant cost. As a banal, perhaps exaggerated example, if you're writing code that needs to store data in a collection and you know that it's going to perform random access to that data on a regular basis, you're not likely to pick a linked list over some kind of array. What @abraae is criticizing is the practice of asserting "best practices" that are likely to be taken out of context, widely propagated and misinterpreted. Knuth's famous assertion "premature optimization is the root of all evil" is an excellent example. People love quoting it, but few seem to take into account the context, to the point that it has been largely forgotten. Here's the quote in its context: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. To be clear, it's not Knuth's fault that people are taking his very rational and sensible advice and reducing it to "yeah, you should totally disregard performance when first writing your code". This is not about pointing fingers and assigning blame, it's about being responsible when offering advice. Knuth's advice was reasonable and nuanced, and it still got taken out of context and reduced to something different and arguably harmful. Now look at Gabriel's advice, which is arguably a lot easier to take out of its context and misinterpret, and imagine the consequences it could have. That is what @abraae is reacting to. EDIT: There's another thing that really, really bothers me about your reply: > Rule #1 of any business: Sales cures all. This, right here, is what I personally feel is wrong with software nowadays. It's how we end up with poorly written, bloated, bug-ridden, unstable, unreliable, insecure crap that we end up using anyway, because there's no better alternative.

jpochtar 8y ago
Ironically, Knuth's full argument is exactly what we're saying, and what @abraae's taking out of context to criticize. See https://medium.com/@jaredpochtar/on-performance-and-software-engineering-44eefa90d46f https://medium.com/@jaredpochtar/on-performance-and-software... and the full section on https://medium.com/@gabriel_20625/technical-lessons-from-building-a-compiler-startup-for-3-years-4473405161cd https://medium.com/@gabriel_20625/technical-lessons-from-bui... > Most of the code we wrote was fast enough (<2ms) that making it faster wouldn’t be noticeable, so it would definitely be a waste of time to optimize. Making code that’s 0.1% of your runtime 100x faster only makes your latency <1% lower.

cr0sh 8y ago

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).

Twirrim 8y ago
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.
- donavanm 8y ago
  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.
taneq 8y ago
> "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".
- 8y ago

Aeolun 8y ago

> You know what's really hard to sell? A product that hasn't even made it out of the damn door yet. I don’t know about this. I generally end up building the things that have already been sold.

WhitneyLand 8y ago

Can your comment help anyone? It seems to be within the set of concepts and suggestions that cannot fully sink in and be truly appreciated until some degree of failure or experience relating to them has occurred. Yeah, they read it. they get it. But they still don't get it, if you know what I mean. But wow - this one sure does take on some laser etched permanence once it does get through.

quickthrower2 8y ago

Just apply some common sense and paretos rule. I.e don’t do something dumb because there is no measure. E.g. a loop that needlessly iterates a billion times.

zimpenfish 8y ago

I once had a multi-day argument with the other 2 devs on the team about whether a set of MySQL queries and code would scale to thousands of reporting devices. My stance was that it didn't matter because if we didn't make the TWENTY devices we had work by next week, we'd lose that contract and pretty soon our jobs.

lucideer 8y ago

The commenter you’re replying to isn’t saying “performance first”, they’re just saying “performance matters”. In other words—don’t go to extremes in any direction. It sounds very much like this conpany took an extreme perf-first approach from the outset, and advocate a reactionary overcompensated opposite extreme in their postmortem.

manquer 8y ago

It is not that simple. While premature optimization is definitely a problem, In my experience not handling it correctly before the app is in prod usually results in having to fix logical bugs , refactor for performance and add new features users are clamouring for at the same time. We don't get lot of chances with users to say you will eventually fix these issues for them, you will simply loose them . As all things there has to be a balance between both ends