7 ms·

IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they wri

• TeMPOraL 2mo ago
  Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.
• tayo42 2mo ago
  You've really seen a web software product die because of performance issues?
  • sscaryterry 2mo ago
    Yes, it is hardly ever the web-side of it though.
    • rockemsockem 2mo ago
      By "web-side" you mean the client side I assume?
      • sscaryterry 2mo ago
        Not at all. It is usually the database :)
        • rockemsockem 2mo ago
          Yeah, that's what I figured you meant. It absolutely is usually the database, guess you're also saying it's not the server-side either lol
  • crazysim 2mo ago
    Wave waves at you from the grave.
    • shric 2mo ago
      Did Wave have performance issues? I thought it was amazing, they just killed it because it didn’t have enough adoption
  • saulpw 2mo ago
    Friendster
  • Plasmoid 2mo ago
    Healthcare.gov was a national scandal due to poor performance related to bad requirements gathering.
    • cben 2mo ago
      I'm not american, and didn't follow that one deeply, but presumably that's not just "due to bad req. gathering", it's also due to the structure of gov procurement? E.g. it wasn't the pained users who approve the payment to the contractors, right? You could counter "if only performance was legally included in the contracts, a better site would be delivered." Maybe, but my point is there is big difference between internal "req. gathering" that informs work while everyone is long-term motivated for good user experience anyway, vs. external contract/deadline gathering for almost adversarial "deliver worst thing that passes and walk away" settings. Brushing both under same wording feels insufficient to me.
  • prmoustache 2mo ago
    Web software I don't know but there are many "modern software" that were meant to replace COBOL code running on AS400 that ended up never making it to production because they were running so badly and projects ended up being money pits.
  • nunez 2mo ago
    The $32M Hertz scandal The $480M bug that killed a trading company in 12 secs Challenger Probably a bunch of stories from healthcare
    • MomsAVoxell 2mo ago
      No. Software failure was not a factor in the Space Shuttle Challenger disaster.
    • KptMarchewa 2mo ago
      >The $480M bug that killed a trading company in 12 secs It was a flag reuse issue. Nothing related to "performance"
• zormino 2mo ago
  I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.
  • geon 2mo ago
    Getting to a state where those assumptions are true is HARD. And takes a lot of careful programming. Yes. Once it is true, the code is easy to write. But only because a lot of effort went into making it easy. And keeping it easy is also hard. Without focused effort to keep the code clean and easy to modify, it starts to rot.
• chasd00 2mo ago
  I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
  • manphone 2mo ago
    That’s because fundamentally you need those strategic items to have space to do those particular detail items. If you have the best strategy and no execution, you can probably hire for that. If you have no strategy and decent execution, you are driving the Titanic into the iceberg.
  • samdixon 2mo ago
    > stakeholder buy-in Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
  • rockemsockem 2mo ago
    I did not mean to imply that consensus, stakeholder buy-in, and strategic direction are easy, or even that they are easier than writing good code. My point is just that the code part is not easy either. I think the article's point that "if good code was easy, we'd have amazing software everywhere instead of crappy software everywhere" is a very good one. The average code that gets written is horrendous, interviewing people who are presently employed and struggle to write a for-loop makes this really apparent.
    • conductr 2mo ago
      A lot of those performance issues in enterprise systems are platform specific to begin with. I’ve never seen what I’d call a high performance ERP, even when on the cloud. It’s usually poorly documented. It’s unclear when a pick list passes QA today well, but in a year with the list exceeds X items, the whole application crashes or grinds under the weight. A lot of time these things are learned via scar tissue and could have been easily prevented if better standards or documentation was in place. I’ve used a lot of Oracle ERP products and I always comment about how poorly their queries run for a database company. It used to be thought it was a hardware issue and they’d sell you accelerator licenses, but now that I see more and more I’m convinced they just don’t care about performance. They want it to slow down so they can sell you more. That, and the feeling that when you build a platform for all, you’re building a solution for none. Meaning, it’s such generic and customization heavy they can always point back at you and say it’s your implementation that’s problematic not our platform. Sometimes that’s true, but also when I pay what I pay, I should get better performance irrespective of how I implemented it. I run a simple query often that’s basically selects all the accounts numbers and names from my chart of accounts (accounting), this is a central and core part of the ERP, why does this query take 45 seconds to return 200 rows of 2 columns wide.
• buran77 2mo ago
  > a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. On those complex systems in particular the problems start long before any code is written. A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types. For the first group code was never the hardest part. For the second group there was never any other part.
  • blub 2mo ago
    No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software. Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc. The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road. The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
    • buran77 2mo ago
      > but many details Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete. > Code is a form of low-level design and is where the rubber hits the road. Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it. > The best requirements, designs, marketing, etc are worth jack if one fucks up the code. Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing? Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
• znpy 2mo ago
  Knowing what to do “wrt the code they write” is directly consequential to knowing what do at all, you proved the original point correct.
• try_the_bass 2mo ago
  > IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement. In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways. There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
  • rockemsockem 2mo ago
    I think architecture is overemphasized a lot. I am quite plainly talking about writing code that runs efficiently to support a wide-variety of tasks. To do that, one needs to write code that runs fast on your targeted platforms and is extensible/easy-to-modify (not necessarily the same thing to be clear). We may have different definitions of "architecture" though, I tend to think of "architecture" at the system level, i.e. "this service handles these responsibilities, this other one handles these, they communicate with this interface/contract, etc". I can see how you could take the term "architecture" down to a lower level where you talk about classes/files passing information between each other too. I think to do that sort of lower-level architecture well though you basically need to write code in your design, even if it's just pseudocode.
• Aeolun 2mo ago
  > a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.
  • yallpendantools 2mo ago
    I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said. Anecdata time... There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla. The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win. After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs. The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent. After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go. Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.