5 ms·

in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them, they were

• megablast 6y ago
  Or they are unfixable. And explaining why to a non technical pm can take all day.
  • polote 6y ago
    that was not the case, I ended being the one plotting the flame charts as no-one wanted to do it
    • Aeolos 6y ago
      Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performance optimization. Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter. My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle. The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...
      • TeMPOraL 6y ago
        > Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.
        • Aeolos 6y ago
          You hit a vein of truth here, I don't recall any of that being covered in a university course or in any of the companies I've worked with. My knowledge too comes from dabbling with gamedev, programming/hacking underpowered hardware (90's consoles), and spending (too much) time on open-source projects where performance optimization mattered. I don't expect my colleagues to have the same kind of experience, but I would expect someone presenting as a "senior frontend engineer" to understand the GC impact of allocating thousands of objects in a tight computation loop; or of doing heavy computations / updating the DOM inside a mouse move event handler. On the other hand, Slack is worth $27.7B and is still selling a product that has frustrating multi-second delays on standard keyboard interactions, so I don't know. Maybe I am really just expecting too much.
      • yellowapple 6y ago
        That raises an important question, though: is it really true that the developers don't care? Or is it more a matter of these performance improvements falling to the wayside because management pushes features and/or bugfixes first? I've definitely seen both in the wild, so it's an important question to ask every time, rather than sticking to a blanket assumption of "devs neither understand nor care about performance optimization".
        • Aeolos 6y ago
          That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will have to optimize this before we can do Y", which are totally fine and laudable. However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that. And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
          • webmaven 6y ago
            > And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field. Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
          • yellowapple 6y ago
            > slow bloated Electron apps - except VSCode which is fast Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :) It's certainly faster than Visual Studio, but it also has far fewer features.
    • deleted 6y ago
      [deleted]
  • Cthulhu_ 6y ago
    At some point you will end up with a maximum, a "best I can do with this code", but it's often a constraint because of the underlying architecture; you can't make Angular any faster, but you can consider shifting to a different framework. You can't make webapps any more memory efficient, but you can consider building a native app. You can't make processing a TB of data on a single computer faster, but you can consider making it a distributed, horizontally scaled task.
    • MattGaiser 6y ago
      Do you want to give a non-technical that option? As they could easily just hear the "here is how to fix it", ask for it, and then be left wondering a week later when the project is back at square one.
  • Tepix 6y ago
    We are very far away from "unfixable" performance issues pretty much everywhere, except perhaps in the demo scene with hand written assembly code and in some shader code running on GPUs.
    • tjansen 6y ago
      In theory you're right. In real life, it's unlikely that the developers who were (probably barely) able to implement the system in a high-level language are able to rewrite and it in assembly code. And even if they were, unless you don't intend to change the code ever again, it's more likely you're just piling up technical debt.
      • _ph_ 6y ago
        Assembly isn't a good example, there are plenty of high level languages which produce excellent compiled output. But you have to use those, not any fancy new language or framework. But your point is correct in that in many projects there isn't enough budget to make the product faster. Which is a project management decisions, not that the speed issues are unfixable.
      • ori_b 6y ago
        Are you seriously suggesting that there's no improvement to be had in the typical ui without rewriting in assembly?
• jlokier 6y ago
  I find that quite fascinating. I love making things perform faster. It's one of the most rewarding things to do as a programmer, and "low hanging fruit" optimisations are usually quite simple, "mindless" work, to do in a quiet period between solving hard problems. The wins are easily measured. It can take a long time to do in a complex system, but it's usually pleasant and relaxing time.
  • Elte 6y ago
    Yeah same here! Nothing like watching a 200ms timer go down to 100ms just because you swapped out some data structure or cached some variable. It's a very satisfying game to me.
  • dawidw 6y ago
    Indeed. It is such a pleasure to work on purely technical challenge - no BAs, no meetings, no customers - just you and the code.
  • tjansen 6y ago
    I also love to optimize code, but I know many developers who wouldn't even know where to start.
    • sumtechguy 6y ago
      I always start with timing it. The thing is many projects I end up in it feels like a death by a thousand cuts. Every sub function is very quick but overall together they take up tons of time. I worked one project where I took logins from 6 seconds to sub 100ms. No one cared or even noticed. Even though it was top 10 on every metric we had.
  • kranner 6y ago
    Same here. The two most interesting parts of programming to me are optimisation (mostly speed, sometimes memory though it's not needed as often) and debugging (especially when I can just reason out where the bug must be and it turns out to be correct).
  • 6y ago
• _ph_ 6y ago
  Provocatively asked: who was right? This sounds more like an organizational problem. The project leader has to decide whether speed issues need fixing or not. If they don't need fixing, then it is indeed a wasted resources trying to do so. If they need fixing, then of course it is the task for the project leader to find the neccessary resources. Speed issues are almost never unfixable. But, the cost of doing so might be prohibitive, usually companies deliver products which are just fast enough. The question is, with a given budget, how do you ship the better product for the customers needs? Do you want it to be fast with fewer features or not quite as fast, but having many more required features? To decide this, it is the job of the project lead, the architects and of course marketing, which has to sell the product. And both as a project lead and a developer, I can say, it is really fun to make something faster and more efficient, but far too often there isn't the time/resources for it. Most of the time you have a customer waiting for new functionality or bug fixes much more urgently than for some speed improvements.
  • CaptArmchair 6y ago
    This comes down to defining and generating "value". Speed, features and bug fixes are all different forms of value. But value isn't an absolute. It's always in the eye of the beholder and depending on where a stakeholder is coming from, they are prioritized differently. From a business perspective, balancing between different types of values is paramount. The end goal, after all, is to always deliver value that generates revenue exceeding expenses at an acceptable level. This is why legacy software is a thing. The business assesses that an old tool still generates value for paying customers and revenue while spending an acceptable amount of time on maintenance. In the context of a large system with a large userbase, this may imply dedicating one or two developers full time towards keeping the lights on. Many software projects don't get a rewrite. Why? Because over the course of years, business and technological contexts for all stakeholders - both the business and the customers - change so much that they become irrelevant. For instance, the business pivoting away towards a new lucrative market or product, or customers moving away to a competitor offering the same value but at a better price point and with up-to-date technology. Just consider many services and products you've used over the years and how many of them have been shelved or sunset without ever being rewritten. While the necessity of a full rewrite may pop up over technical concerns such as security or performance. It's only when business and functional requirements have shifted away to a serious degree from the original scope of the project that organizations tend to consider dedicating time and resources to a successor. At that time, a rewrite isn't necessarily the only option: sourcing a product that does the same thing but better from an outside supplier could be a valid option as well. For instance, chucking away your own homegrown decade old CRM for Salesforce as your business grew from a 5 person outfit to a 120 person business servicing enterprise.
• bryanrasmussen 6y ago
  >in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them In my experience it is always the PM or product owner telling me not to work on improving speed. How slow was the app, I guess the devs would be right if it was like 2 seconds or less to load/render, at that point working on speed has diminishing returns.
• mattmanser 6y ago
  So I've done this a few times and constantly play with the idea of offering it as a consultancy service. Two things put me off, I do wonder if anyone else here has attempted to do it as a consultant? Firstly, while I could quickly identify the cause of the slowdowns, the previous times I've done this I already had an intimate knowledge of the codebase so could confidently fix the problem. Without an intimate knowledge of the codebase, I fear I'd either muck up the fix, or that I'd have to rely on internal developers who, as you say, would deprioritize it or feel resentful at an outsider coming in and from their perspective effectively telling them their code is "bad" (even though I understand how these speed issues develop organically). Or would it be enough to just offer the diagnosis, but not the fix, and thus give ammo to the PMs/senior management to take the problem to their own developers and say "look, we've been told there's a problem and it's fixable, go fix it". Secondly, how to handle getting access to their codebase/a proper debug environment that reflects production for such a short time. Again I fear it would turn into a "not my problem" scenario of trying to get a live environment setup from people who don't want to give it to you. Fixing these problems usually turns out to be fairly quick once you've identified the real cause. I can do a quick analysis just with access to a website (i.e. is it a back-end or front-end problem), but until you can run diagnostics you can't say exactly which loop/sql statement/js compilation issue/etc. is causing the problem.
  • bsenftner 6y ago
    My solution to this issue to to hire only former C/C++ video game developers for non-video game software development. Their attention to performance is innate, their attention to critical obscure details is innate, and their desire to write code they are proud is innate. Plus they come with advanced, useful math knowledge. I love former game developers because they did the pop culture dev job, saw it was exploitation, and took their incredibly optimized skills elsewhere.
    • mattmanser 6y ago
      It's good it works for you, but in terms of webapp development, wouldn't they have very little skill at databases? And focus on optimizations that are completely irrelevant for 99% of webapps? I've seen before code where premature, pointless or unclear optimizations used, like dogmatically using stringbuilders or avoiding boxing saving all of a couple of nano-seconds, while the SQL statement is taking 3 seconds to run due to unnecessary sub-selects because the developer doesn't grok set-based logic. Or worse, cursors because they think they need a loop!
• nicoburns 6y ago
  It's actually easy in JS frameworks too (at least React, not sure about Angular which is just generally more difficult to work with). In fact, they make it much easier to write performant UI code (that's half the benefit). You generally don't need to debug the framework. Just follow some simple best practices and the performance will just happen in 99% of cases.
• sangnoir 6y ago
  > It is easy to debug a js function, but what about when you use angular or any other js framework ? As someone who worked on a successful web-application perf-improvement project in a past life, my top 3 tricks were: 1. Profile, and use flame-graphs & call-graphs (with counts) to identify which parts are slow 2. Don't do unnecessary work 3. Execute code asynchronously whenever possible (requires balancing with code readability) Not doing unnecessary work may be straight forward, and sometimes very complicated. Simple: some results are discarded, or some expensive functions are called for a minor side-effect just because developers were told to "maximize code reuse" at all costs. Complicated: understanding which function calls that unexpectedly block/delay browser rendering/painting