11 ms·

One absolute rule for success in software is that there are no absolute rules. From their post mortem https://medium.com/@gabriel_20625/technical-lessons-from-

• lbotos 8y ago
  I think you missed the gist? They are saying if you are saying "this piece needs to be more performant" you need to measure that first, before making your choice of what to make better. You are saying, "you can with an idea in mind optimize before you go and it will have better performance" but the current prevailing business logic is do not optimize until you know it's "the right thing". AKA premature optimization is bad. Did I mis-interpret what you are saying?
  • ams6110 8y ago
    I think GP is saying, if you are at a point in development where you can choose A or B, and A has foreseeable better performance or scalability, all else being equal choose A. A lot of assumptions there and real world is almost never that clear-cut. The general advice of "don't optimize until you've measured" is still almost always correct.
    • magicalhippo 8y ago
      > The general advice of "don't optimize until you've measured" is still almost always correct. The issue of course being that when designing code, various design choices can have significant performance implications, and can be very hard to change once implemented and in production.
  • abraae 8y ago
    I'm saying there are very few real black and whites, and everything in life and in software is more kind of grey. As such there are very few black and white rules you can follow and succeed. The correct approach is somewhere to the left of "premature optimization" and somewhere to the right of "don't even think about performance until you can measure it". More experienced and talented people will be more successful at picking that sweet spot. Telling a dev that the correct approach is to pay absolutely no attention to performance before it can be measured is ... crazy IMO. I would expect them to have at least thought about it, and have some opinions, just as they should not have put excessive effort into prematurely optimizing things they don't know are going to be a problem. My point is - its grey, use your brains, don't buy into absolute rules.
    • eleclady 8y ago
      Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.
• WillPostForFood 8y ago
  Paragraph 3 We don’t think any lesson here should be taken as an “always true” type thing.
  • abraae 8y ago
    Which is entirely inconsistent with the statement "Performance is never a justification for anything if you haven’t measured it".
    • scarejunba 8y ago
      Dude. This is just how people talk. It's called hyperbole and it's a rhetorical technique. Like "never talk to the cops without a lawyer". Really? Never? "Hi, nice to see you guys here. This is my husband. He's a policeman" "I would like to talk to my lawyer" Because we know the world isn't black and white we're able to interpret these statements. It's human speech. Lots of the details are left out because conciseness is gold.
      • abraae 8y ago
        Yeah, I get that, I really do. But what you mean is that you are able to interpret these statements. Plenty of others, maybe less experienced, are not. Next thing you know, they are spreading the word - "hey, did you know there's a new development methodology? The idea is that you completely ignore performance until after you've written some code. Yeah, you heard me - completely ignore!. It sounds crazy, but that's how it works!"
• darkerside 8y ago
  > Performance is never a justification for anything if you haven’t measured it A "justification" implies that there is a compromise being made in the name of performance. It's very reasonable to choose, in the first iteration of a program, to choose to disregard performance concerns in favor of readability, which is exactly the context of how they framed it. When you make the big initial decisions based on readability, that informs all the rest of your choices in working on that piece of code. If you skip a few steps ahead because e.g. "we're making some extra database calls here, so we should grab all the data we need the first time instead", you'll find it much more difficult to optimize your way back to the most readable code possible. Is it the only way to write software? Of course not. And it may make more sense for the systems and frameworks they use than for yours. But I for one admire their willingness to have a point of view and a principle when it comes to writing code. I don't think it's madness. And I don't think you're wrong either. I just don't think you would have been a good fit for their team. By putting their philosophy out there, they help make that clear. And likewise! I don't begrudge your philosophy, and I think it's often correct. But please don't accuse others of drama and clickbait for describing strong opinions.
• z3t4 8y ago
  Only 20k LOC in 3 years is impressive. And I agree that you should watch out for premature optimization an premature abstraction. What i found most interesting was using coffeescript that compiles to js that compiles to react that compiles to js. They might have been too focused on the technical side. You should probably pick the most boring and proven tech stack and focused more on the actual problem.
  • jpochtar 8y ago
    Thank you! I'm one of the cofounders— keeping LoC low was one of our primary measures of code quality. > we were too focused on the technical side Yes. Oh boy we were. > should probably pick the most boring stack Agreed. I'd worked in the Coffeescript compiler so it was "boring" for me, but you should pick whatever's "boring" for you— likely not Coffeescript
  • jtreminio 8y ago
    Would you say the same thing if they were using Typescript instead of Coffeescript?
    • z3t4 8y ago
      An actual problem might be how to generate a responsive design for "mobile" and different screen sizes. That's what you should focus on. The problem with picking new cool tools and languages is that you might end up solving dev/sys-ops issues, learning how to use them, and develop additional tooling, instead of solving actual problems. Unless you think it's a really good fit for the actual problem domain and thus worth the extra investments.
• aspencer8111 8y ago
  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.
• jpochtar 8y ago
  Hi— Jared from Pagedraw here. (Stunned that this is the top comment on HN.) I stand by what we wrote 100%, but to add some color: I don't want you to think we didn't care about performance. We did— a lot. We just think most people do performance optimization badly. There's a lot of superstition on the internet about how to structure your code so it's fast. In our experience, following this advice usually does not make your code fast. Most people have bad intuition about performance. To counter this, you have to constantly measure the performance of your code. There's 2 parts to this idea. 1. Most things are fast enough that optimizing them is not worth making the code less readable, and is a waste of time. 2. Measuring, rewriting, and repeating is the right way to do performance anyway, full stop. There's lots of superstition around performance, which is absurd because it's extraordinarily measurable. For point 1: We goalled on a clear and flexible style, which helped us move incredibly fast with very few people. See https://norvig.com/spell-correct.html https://norvig.com/spell-correct.html for an example of a golden piece of code in this style. Rewriting for performance takes moves us away from that goal. 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. It's not because we're brilliant coders: we just realized that most of the code we wrote ran on arrays with few enough elements that even O(n^2) algos could run in <1ms. Some of the code we wrote ran on a server, where network was the dominant factor, and we could always just scale up our servers with money. Some of the code ran on click, where it could be as slow as 5 seconds without the user really caring. For point 2: There's no such thing as “fast” code and “slow” code— you can put in the work to optimize any piece of code, and make it incrementally faster. Because you can put in work to optimize any particular code, we either budgeted hours of engineering time for performance, or set performance goals. In either case, you want to spend your time optimizing the code that's the slowest, so you get the most “bang for your buck.” Most people have terrible intuitions about performance. We certainly did— if we'd prematurely optimized the things we'd thought were going to be slow, we'd have wasted a ton of time I felt there were lots of superstitions about performance that were just wrong. For example, considering big-O time complexity was often wrong for us, because our n was usually pretty low, so we were dominated by constant factors. Performance is incredibly measurable. You should always measure, rewrite, and repeat until you hit your perf budget. Otherwise you're just shooting in the dark. Because we goalled on clean code, tearing and replacing whole subsystems for performance was relatively easy.