In this case you have massive scale so a small amount of developer time can equate to a big reduction in CPU cycles.
Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers.
My point is that your job is only to tune performance iff there is a solid business case for it.
I spent a week reducing a pages load time because the busines saw the load times as a problem for customer acquisition. The cost of my time was justified. Meanwhile we had a task that for 6 years took over an hour to run. I optimized it to take less than a second. That change has offered zero business value and was a waste of time. It runs periodically on a server that is most often idle. There was no justification for that work, other than it taught me to align my efforts with the business.
CPU cycles are much cheaper than developer hours. But yes, if you have enough of them yes they will cost more than a developer.
It's not a massive scale at all! It's just "Enterprise" edition software (SQL Server, etc...) that costs $$$ to scale up.
The actual production platform is just a dozen or so virtual machines, they're not even that big.
Not everybody has their own data centre where they pay cost-price for all-Linux servers that run only free software.
In a typical business that hosts their servers in the public cloud, it's not unusual for a single database index to allow savings of tens of thousands a year.
E.g.: SQL Enterprise on an Azure E8bds_v5 VM is $2,678 per month, but the next step up to E16bds_v5 is $5,355 per month!
If you can optimise a database so it can move from 16 vCPUs to 8 vCPUs then that alone saves $32K annually. This is ignoring ancillary costs such as the second DR instance, etc...
Sure that makes a lot of sense, I'm sorry for my bad assumptions, but that drives my point home even more. The problem is not related directly to your performance on the hardware. It's an additional cost from the business environment. License costs can drastically alter where your efforts are best spent. I'd imagine there are times where you might be better off pulling huge chunks of data out of the database to process on machines that don't have such a big license cost.
CPU cycles are cheap, SQL Server licenses are extortionately expensive. While the costs are tied to the server they run on if you can offload to a different CPU not tied to that license model you can still take advantage of the low cost of CPU cycles.
But people aren't. Any code that "makes people wait" is wasting people's time. The only way to make code take less time is to optimise it, because capacity != latency. You can't get a 20 THz processor. You can buy more capacity, but you can't buy more speed!
At FAANG scale, it's common to hire "top" developers at hugely expensive annual total comp to tune stdlib code like "string" for just 1-2% efficiency gains because at their scale that might be 1,000 to 10,000 fewer servers.
At a small scale, budgets are tight.
At "enterprise" scale, staffing (user) costs are high, and license costs are high.
I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap".
>I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap".
Say you're a small business with an in house server rack. Not a software company but say a manufacturing business. Not enterprise scale, smaller. You have 1 development resource. It turns out the ETL server is overloaded and it's causing the reports that run on the same server to run slow. You could get the developer to spend a few weeks porting the legacy system to faster modern option to speed up the ETL and maybe improving some of the reports. But it would be far cheaper to buy in another server for $3k and have the developer spend less than half a day moving the ETL onto the fresh server.
On which... it'll run at maybe 20% faster, because that's the scale of single-threaded processor speed improvements these days. Not to mention that now there's a network hop involved, which will eat into any CPU gains.
Very few apps scale well with increasing core counts, and then hit a wall around 64 cores for almost everything.
Okay, okay, fine. The ETL is natively parallel code and somehow, magically, it can read inherently sequential file formats like multi-gigabyte CSV or JSON files in parallel. This tiny org already has 10 gigabit switches, SFPs, and everything.
Did you upgrade the database server too? No? Now the shiny new ETL server is twiddling its thumbs while the database server is getting overloaded.
Suddenly this option is "not so cheap". You have to buy a new database server and... uh-oh... it's Microsoft SQL Server, Oracle, or SAP HANA, and the licensing is going to eat half your tiny little company's profits for the year.
Did you forget the OS license, backup agent license, anti-malware license, and so on? I bet you did. All of those are extra, and either per-machine or per-core.
Someone has to set this all up. Small non-IT shops typically outsource this to an IT service company. They'll explain all the extras that turn a $3K purchase into a $30K purchase (including on-site assistance to install everything).
Or that 1 guy could have just taken a 10 minute look at the ETL logs, discovered that "SELECT * FROM HugeTable" is unnecessary, and fixed the problem.
Don't forget your electricity costs, A/C costs, hardware maintenance costs... these are often overlooked, but are not nothing. You've added permanent recurring expenses to avoid your one-time developer fee.
Yes, sometimes this might make sense --- if the dev fees are going to be exorbitant, or if you just can't afford to pull a dev off a project to work on it. Other times, it makes more sense to pay the dev...
You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.
>You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.
Yeah that is fair. There is a lot of missing information. I'm only trying to across that now days developer time is often expensive and hardware is often cheap and powerful.
I don't like the idea that our goal is always to make the most efficient code possible. It's not, it's to deliver business solution as efficiently as we can with the resources available. Just like you wouldn't want to pay for a mechanic to spend a week making your car more fuel efficient if you took it in to get new engine mounts. His job is not to make your car work for you, not work the best it possibly could.
That said most of the time you do want to be writing efficient code.
> I don't like the idea that our goal is always to make the most efficient code possible. It's not, it's to deliver business solution as efficiently as we can with the resources available. Just like you wouldn't want to pay for a mechanic to spend a week making your car more fuel efficient if you took it in to get new engine mounts. His job is not to make your car work for you, not work the best it possibly could.
If he could get me a 1000x gain in fuel efficiency, like you often see when software when performance overhauls are done, I would sure as hell give him his week. But this is less about maintenance and more about how the car/software is built the first time around.
In that vein, I do expect that if gasoline prices drop to $0.20c/gallon in a decade (hah), that fuel economy on new cars does not drop to 3mpg to match. That's essentially what seems to have happened in software --- the hardware got really fast, so software got really slow.
> It's not, it's to deliver business solution as efficiently as we can with the resources available.
This is true; I guess what I take issue with is externalizing hidden costs to the customer. We keep paying for faster and faster hardware, and have to because that old hardware which is still working perfectly fine can't run the new software, which is much slower. And often, even on new hardware, the software is just this side of "tolerable". If you're writing your own in-house tool and nobody cares, do whatever suits.
> That said most of the time you do want to be writing efficient code.
Yes. That's all I want. Reasonably efficient. Not balls-to-the-wall speed demon witchery like we saw back in the demoscene heyday, just not to be sliding backwards all the time to erase all the gains our hardware got us.
---
EDIT: I get where you're coming from with the business incentives, I really do. But I'm saying I have a lot of issues with the end result --- as is often the case, maximal profit for the business is wreaking havoc elsewhere, in a sort of tragedy of the commons effect. And there are no realistic ways for me as a consumer to alter business incentives. A lot of software, especially the type that people get paid to write is closed source and closed protocol.
An excellent example is Discord --- it works well enough, when it works, but it's kind of a big heavy behemoth. It doesn't run well on older computers (I frequently see it burning a whole core just sitting in a voice channel). Right now, it's using nearly 1GB(!) of RAM, and frequently climbs to 2 or more if I leave it run long enough. This is a program whose core functionality was essentially available to me in 1999, and it struggles if I try to run it on a 4GHz machine from 2012. The search function sucks imo, and various other complaints. Screensharing with audio is broken (because electron), and probably always will be.
And I can't do a damn thing about it. I can't use a different platform, because the platform I use is determined by the people I want to talk to that are already using it. I can't improve or fork the program, because it's closed source. I can't (realistically) use a different client, or even write my own, because it's a closed protocol. So I'm just stuck with this pig of a program, and no amount of rage or frustration that I feel will alter the company's business incentives.
But it's just one program, right? Okay, I've got the cycles to spare, and the RAM, well, I overprovisioned this machine, so (in the case of this one, relatively modern machine), it's not the end of the world... right?
Now add Spotify. It's the same damn problem, so now the problem is 2x. Add a web browser (I mean, one who's job is actually to browse the web). I manage to draw the line there, mostly, but a lot of people are stuck with a lot more (VS Code, etc). It all adds up to a nightmare. And yet, all the time, I hear how "performance doesn't matter" (not exactly your words, but a prevalent developer sentiment).
>My point is that your job is only to tune performance if there is a solid business case for it.
I think its very very hard to put a cost on performance.
A few seconds here or there is very draining on people. How do you measure if people are avoiding doing things, or putting off work because their tools are janky. How do you measure how much time people spend complaining about how slow their computer is?
If they are a normal business admin they are very replaceable. So you don't have to make life easy for them unless they can justify the cost of doing so.
How busy are they?
If you have a 1 EFT position filled by an administrator that is only 60% busy then there is no cost in slowing them down until they're at 100% capacity. Then you might think about making life easier for them to avoid having to hire the next administrator. If people avoid doing their job because they don't like their tools that is a disciplinary matter. Time to find an administrator that can do the job required.
> If they are a normal business admin they are very replaceable. So you don't have to make life easy for them unless they can justify the cost of doing so.
That is a mentality which is too horrifiying to find proper words to describe.
> If people avoid doing their job because they don't like their tools that is a disciplinary matter. Time to find an administrator that can do the job required.
It's human nature to avoid difficult things. Discipline only goes so far; it happens subconsciously.
And anyway, small inefficiencies add up to mountains, but it can be hard to see what's going on when everything is just pebbles everywhere.
I dislike government intervention, and so disavow my following statement.
In the course of fining hidden externalized costs like those of dumping chemical waste into rivers, governments might fine software developers when they dump informational waste on to customers' machines, and if it does, they'll deserve it.
Anyone who ships an electron app goes to the gulag.
I dislike government intervention, and so disavow my following statement.
In the course of fining hidden externalized costs like those of dumping chemical waste into rivers, governments might fine software developers when they dump informational waste on to customers' machines. In this hypothetical, they deserve it.
Anyone who ships an electron app goes to the gulag.
Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers.
My point is that your job is only to tune performance iff there is a solid business case for it.
I spent a week reducing a pages load time because the busines saw the load times as a problem for customer acquisition. The cost of my time was justified. Meanwhile we had a task that for 6 years took over an hour to run. I optimized it to take less than a second. That change has offered zero business value and was a waste of time. It runs periodically on a server that is most often idle. There was no justification for that work, other than it taught me to align my efforts with the business.
CPU cycles are much cheaper than developer hours. But yes, if you have enough of them yes they will cost more than a developer.