The reality is that they didn't know how to fix the speed issues.
It is easy to debug a js function, but what about when you use angular or any other js framework ?
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.
I don't think you can offer it as a consultancy service because people tend not to care and are quite aggressive about that. They would much prefer to pay for more hardware and doing so is organisationally respectable: "the cloud will solve our problems".
I think programmers might not care, I'm not sure their managers and PMs don't.
Hiring ex C/C++ game developers is fine on the surface. They are smart people and can pick up things quickly.
But as a general rule it fails.
Taking longer to get things perfect is usually not a tradeoff in the webworld that makes sense. People want simple, reuseble and quickly changable features. Pixel perfect perhaps but never code perfect because things change quickly. Why would you hire for that?
Higher salaries for no reason.
Learning curve will be harder than one expects
Smaller pool.
Greater unhappiness. You might hear after writing a game engine that web work is 90% easier but so boring.
Hire an ex c/c++ developer because they show an interest in making a change and are willing to put in the work. Don't hire all of them and expect an advantage..
Also, the typical game is significantly larger than any single gamer experiences, and game developers certainly know the tradeoff of "good enough". Plus game production environment is a technological feat in itself too, and it is those type of game developers that contain the most value - not necessarily the game play developers, but the game production pipeline developers.
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!
Just like I can't imagine the true depth of complexity of game/3d development having dabbled making games in unity, I'm not sure you understand just how complex a sass/enterprise site can get, it's usually issues with actually organising the code that gets you, rather than the code itself.
Your example of i18n is actually quite telling, having internationalized a couple of sites that's actually a fairly simple organizational problem in our codebases, comparatively not really complex at all, just tedious.
My example intended to reference more than i18n, as that only covers the interface. Consider something like an online international university where there is media, but that media varies with 8 different languages, so each and every aspect of any presentation needs to accommodate variable length text fields, left and right and vertical directions of text display, every media clip varies in length due to language, and multi-language users can switch display mode at will. I've done projects like this, over a dozen, and it's quite the challenge.
The company I worked for offered very expensive timesharing by the hour. Clients used an "Englishy" interpreted language to do economic forecasts, and client staff often programmed their own procedures.
My boss came to me one day to request that I speed up something a client had developed themselves, because it had become too expensive for them to run, and they were ready to bolt.
I had no desire to understand what their code did, and so treated the code mostly like a blackbox, and my job as speeding things up while leaving the transformation of inputs to particular outputs intact.
I had enough experience to know what the low hanging fruit were and went after those in the code. A day's work or so, and we got a 50-90% speed-up, enough to satisfy the client. I still don't really know what the code did. But I enjoyed the effort.
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.
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.
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.
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.
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
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.
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, ...
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.
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.
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".
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.
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.
Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
here in my city I can pull out a sticky mud-encrusted motherboard and GPU from the flea markets - scrub it down with a bit of isopropyl alcohol, and put together something as responsive as a 2015 macbook air for 20 euro (PopOS is a favourite for this).
in an agency, you have an MBP thrust upon you, and your software “works fine on [our] computers”. end users still be running a last generation of CPU will eventually decide “I need a new computer”, and the cycle is complete.
its not that developers dont care, its that they’re never given the chance to care under these ... circumstances.
> This performance management works by looking at a combination of the device temperature, battery state of charge, and battery impedance. Only if these variables require it, iOS will dynamically manage the maximum performance of some system components, such as the CPU and GPU, in order to prevent unexpected shutdowns.
b) At any rate, “Apple deceitfully handicapped older products to cover up a more serious (but fixable) flaw, knowingly pushing customers into unnecessary upgrades” is really not any better than “Apple deceitfully handicapped older devices to push consumers into unnecessary upgrades.”
In this specific case Apple and Samsung have been proven dishonest and manipulative, and they have a far stronger legal/financial incentive to lie than separate groups of prosecutors in the US and many separate EU member states. I also find a conspiracy internal to Apple/Samsung much more plausible than a conspiracy across attorneys general from 34 US states.
Only trusting viewpoints that agree with your personal biases isn't enlightened, either.
> "In this specific case Apple and Samsung have been proven dishonest and manipulative"
is an unvarnished falsehood. The throttling wasn't across the board, it was triggered in specific circumstances related to the state of the battery. There was never any evidence that this was a scheme to defraud customers.
This is the same company that removed the headphone jack for very cynical reasons, in order to increase the sale price of their phone by $150 (or however much the Airpods cost). The same company that repeatedly removed ports from the laptops in order to sell more dongles (so much so that there were running gags at the time about Apple, the dongle company). A company where the revenue from the sale of accessories for their devices could literally make a Fortune 1000 company (!!!).
They definitely knew what they were doing and chose to do the thing that most benefited their bottom line.
Let's stop giving the benefit of the doubt to the top tech companies. They don't deserve it like mom and pop stores.
Oblio's Law: Never attribute to malice that which can be attributed to stupidity, unless the ones acting have an army of data scientists, researchers, market analysts and PR people at their disposal.
Imho there's a reasonable case that they did the thing which best protected users older devices and daily usable time, and I think most users would prefer their phone stays working for a day on a single charge, so they can make and receive calls and messages towards the end of the day.
It's possible Apple wasn't thinking of the users, but it's not a clear cut case.
It's also possible that if Apple hadn't slowed the older phones down as batteries wore out, they would have seen more sales as users needed to replace their phones more urgently as battery life dropped. So it's not obvious that the action they took favoured sales anyway.
Court cases are rarely won, especially with big companies. They have the money to drag them out so most are just settled. So in my eyes any class action lawsuit a company settles for millions is a case they lost.
When will you admit that it was a clear case? They just admitted it themselves by settling!
I give up :-)
Because that is good for the environment :)
If only we could popularize an analogous law for software performance…
Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications. I’ve developed dozens of python web applications. Python is slow as hell, but I can count on one hand the number of times hand where I found the RoI of optimizing a performance issue to be more valuable than feature development (and all of them were problems that couldn’t be solved with more hardware, which is the default best-RoI way to approach most performance issues).
But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.
I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.
What you said about impressing the person viewing the reports really rings true in that case.
I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.
I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.
But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.
Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together.
Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades.
People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app.
> Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications
And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.