Why programmers choose convenience over performance?
Several tools are resource hungry, making it challenging for small businesses to keep up with server costs. Zod for example is 150 slower than regular typeof checks. I wrote small article for those who are interested https://www.drakos.me/article/Zod-is-150-times-slower. The problem is not Zod, but rather the programmers who lack the ability to write efficient code. As I write this, my VSCode uses 4.37GB RAM, my terminal Warp (Built in Rust) uses 976MB RAM and Spotify 1.28GB. These numbers are outrageous to an old senior programmer. Let’s not forget that Nasa managed to launch rockets to the moon with only 64kb of RAM.
24 comments
I think it's caused by the nature of how most companies scale their productivity up, which is by adding more people and creating more teams. As a result the codebase for any given product starts to reflect this organizational structure.
For example, a bank app might have a team for user management, and another team for product management. Then in the bank app, the designers added one module for selecting products on one page, and another module for selecting users on another page... and even though at the implementation level, these two modules are essentially the sam, they are implemented separately, as there is a lot of overhead in communication to have both teams implement one that handles both requirements.
I think this phenomenon guarantees that as codebases grow they accumulate tech debt. As more and more people develop on one application proper global abstractions that would be more efficient are not as common because of how the teams are structured in a way that is not aligned with this abstraction and instead is aligned with how the business side decides to structure teams.
I think it is born from a fundamental misconception of how software should scale as you add more and more features, and typically companies favor adding more people instead of asking their engineers to do the scaling using the software itself. Within a certain domain, there is very little reason not to abstract the implementation of features themselves, which would scale the application just by adding a few lines in a configuration file. Then a single engineer can be developing multiple features in the same amount of time an entire team completes only one. This might just be a blind side of someone who has not studied computer science theory, and instead thinks that if you want more software you need more people.
For example, a bank app might have a team for user management, and another team for product management. Then in the bank app, the designers added one module for selecting products on one page, and another module for selecting users on another page... and even though at the implementation level, these two modules are essentially the sam, they are implemented separately, as there is a lot of overhead in communication to have both teams implement one that handles both requirements.
I think this phenomenon guarantees that as codebases grow they accumulate tech debt. As more and more people develop on one application proper global abstractions that would be more efficient are not as common because of how the teams are structured in a way that is not aligned with this abstraction and instead is aligned with how the business side decides to structure teams.
I think it is born from a fundamental misconception of how software should scale as you add more and more features, and typically companies favor adding more people instead of asking their engineers to do the scaling using the software itself. Within a certain domain, there is very little reason not to abstract the implementation of features themselves, which would scale the application just by adding a few lines in a configuration file. Then a single engineer can be developing multiple features in the same amount of time an entire team completes only one. This might just be a blind side of someone who has not studied computer science theory, and instead thinks that if you want more software you need more people.
I can resonate with this. We do well in a space with a commercial program. It's been under constant development for 27 years. It has never had more than 2 developers at a time (only 2 project leads).
This means the system is "coherent". Things are where you expect them to be, in code, and in the UI. it has scaled very well starting out for "small businesses" and today runs in big enterprises.
One benefit of this leanness is that there are very few meetings. When something is needed by sales, or there's a tricky design question, or hard programming, then a simple ad-hoc phone call moves things along.
That said, having 3 or 4 people going can be advantageous, but team-management goes up exponentially.
This means the system is "coherent". Things are where you expect them to be, in code, and in the UI. it has scaled very well starting out for "small businesses" and today runs in big enterprises.
One benefit of this leanness is that there are very few meetings. When something is needed by sales, or there's a tricky design question, or hard programming, then a simple ad-hoc phone call moves things along.
That said, having 3 or 4 people going can be advantageous, but team-management goes up exponentially.
Do the tools save developers time? Do the tools make deployment or code more maintainable? Is the cost of resources greater than the cost of paying for developers time? They sent rockets to the moon with 64kb of ram because they had to, not because they were trying to skimp tooling.
JFK said so: "We choose to go to the Moon with 64KB of RAM not because it is easy, but because it is hard."
1. Convenience usually transfers to less development time, which means less cost. Unless the performance is so poor that it’s unacceptable to a majority of users, many companies are willing to ship less-performant software if it means saving on development time and cost.
2. There is a lot of software that is used because people must use them. If your workplace uses Microsoft Teams despite its problems, then you’re essentially stuck using it. The problems would have to be so bad that they affect the company’s bottom line in order to switch. If your local bank or DMV requires use to use a poorly-written Web app, what could you do about it?
3. Not all software developers are well-trained in topics such as algorithmic efficiency, computer and network architecture, the trade-offs of different programming languages and their abstractions, etc. There are plenty of developers who could hack up working solutions quickly but cannot write quality production-grade software. The result is buggy software that doesn’t perform well and doesn’t scale.
4. This is just my opinion, but I’ve found over the past few decades that most users are more forgiving about crappy software than the average technically-inclined users. Crappy software isn’t anything new. “What Grove gaveth, Gates taketh away” was a quip I first heard in the 1990s about software bloat expanding as hardware improved. I remember the days of constant blue screens on DOS-based versions of Windows, as well as Macs crashing due to the classic Mac’s lack of protected memory. Complaints about the bloat of Microsoft Office and Netscape Navigator were common. I was a teenager in the 2000s when Windows suffered from many security issues. Non-technical users generally grinned and beared personal computing, all chalking up the crashes and slowness as just part of computing. Us technical types were the ones who were upset enough to seek alternatives. But we’re vastly outnumbered.
As long as economic effects favor “moving fast and breaking things” over slower, more deliberate approaches to development, and as long as users don’t demand performant software, companies will continue to deliver bloated software. I don’t see this changing outside of niches where performance and other related concerns outweigh minimizing development costs.
2. There is a lot of software that is used because people must use them. If your workplace uses Microsoft Teams despite its problems, then you’re essentially stuck using it. The problems would have to be so bad that they affect the company’s bottom line in order to switch. If your local bank or DMV requires use to use a poorly-written Web app, what could you do about it?
3. Not all software developers are well-trained in topics such as algorithmic efficiency, computer and network architecture, the trade-offs of different programming languages and their abstractions, etc. There are plenty of developers who could hack up working solutions quickly but cannot write quality production-grade software. The result is buggy software that doesn’t perform well and doesn’t scale.
4. This is just my opinion, but I’ve found over the past few decades that most users are more forgiving about crappy software than the average technically-inclined users. Crappy software isn’t anything new. “What Grove gaveth, Gates taketh away” was a quip I first heard in the 1990s about software bloat expanding as hardware improved. I remember the days of constant blue screens on DOS-based versions of Windows, as well as Macs crashing due to the classic Mac’s lack of protected memory. Complaints about the bloat of Microsoft Office and Netscape Navigator were common. I was a teenager in the 2000s when Windows suffered from many security issues. Non-technical users generally grinned and beared personal computing, all chalking up the crashes and slowness as just part of computing. Us technical types were the ones who were upset enough to seek alternatives. But we’re vastly outnumbered.
As long as economic effects favor “moving fast and breaking things” over slower, more deliberate approaches to development, and as long as users don’t demand performant software, companies will continue to deliver bloated software. I don’t see this changing outside of niches where performance and other related concerns outweigh minimizing development costs.
Without sounding elitist I think number 3 is a big one. If you once learn how, writing decently performing software is often straightforward without taking any extra labour.
I wanted to affirm point 3 as well. There's a science in "computer science" that lays dome foundations.
Every month or so there's a thread here asking if college is worth it. Answers are typically mixed, depending on lived experience.
My own lived experience (I could program before I went to college) is that we didn't (especially) learn "programming". We learnt about fundamentals like algorithms, P vs NP, coupling, 3rd normal form, and so on. That affected our programming, but we didn't have "programming classes" (well except the first 3 weeks or so.)
I feel, looking back, that this served me well in the niche I traveled. My day job is basically writing performant libraries.
BUT I'm not in the camp of "computer science for all." There are other degrees at college, in programming, IS, IT and so on. There are lots of shorter courses that can train you up to get a job.
Every month or so there's a thread here asking if college is worth it. Answers are typically mixed, depending on lived experience.
My own lived experience (I could program before I went to college) is that we didn't (especially) learn "programming". We learnt about fundamentals like algorithms, P vs NP, coupling, 3rd normal form, and so on. That affected our programming, but we didn't have "programming classes" (well except the first 3 weeks or so.)
I feel, looking back, that this served me well in the niche I traveled. My day job is basically writing performant libraries.
BUT I'm not in the camp of "computer science for all." There are other degrees at college, in programming, IS, IT and so on. There are lots of shorter courses that can train you up to get a job.
If there was a valid reason to write software that efficiently, besides idealism, I'm sure developers would do so. But there isn't in the vast majority of cases, so we don't. iow computing resources are cheaper than labor.
I'm working on a small web app right now inside a VM and it's consuming around 2.5 GB of ram (and I believe Firefox is taking 2 GB). It's i3wm, tmux, vim, zeal, and php. So theorically, I could work on a 4 GB computer easily. But we have people here hollering that 8GB is too low for a modern machine.
Buying a beefy computer for a developer is cheap, but forcing everyone using your software to default to a 16GB computer isn't. And that's why we get when consumer software takes more ram to run than Windows XP.
Buying a beefy computer for a developer is cheap, but forcing everyone using your software to default to a 16GB computer isn't. And that's why we get when consumer software takes more ram to run than Windows XP.
With the resources systems have today, it is likely not worth the time and effort to optimize to the levels done in the past, though I appreciate it when it happens.
All I ever hear from my management is “when will it be done?” They don’t care at all about resources. It’s not even in the conversation. If there is a resource issue, the general solution isn’t to optimize the code, it’s to throw more compute at it.
All I ever hear from my management is “when will it be done?” They don’t care at all about resources. It’s not even in the conversation. If there is a resource issue, the general solution isn’t to optimize the code, it’s to throw more compute at it.
> Let’s not forget that Nasa managed to launch rockets to the moon with only 64kb of RAM.
We're not in the rocket launching business. Desktop memory is cheap and nodejs/electron makes it easy to develop cross platform.
We're not in the rocket launching business. Desktop memory is cheap and nodejs/electron makes it easy to develop cross platform.
Majority f laptops today are equipped with 8 gigs of RAM. However, this isn't enough because most developers no longer write software based on the current hardware specs of the market as they used to. It's not that it's impossible, they just don't care about user's hardware and they focus on developing software with lot's of features.
Tell that to the user that try to run Spotify, Teams, (Outlook Mail?), and other electron stuff. I don't think it's that much hassle to write a <lang> core and use FFI or RPC with each OS native platform UI (or use QT).
A decompressed 4k texture uses ~80-90MB of VRAM.
Your development tools index millions of lines of code.
Not sure what your terminal does tho.
But finally it’s mostly the massive amount of data modern applications have to handle effectively that lead to large amounts of memory allocated.
Zod surely is slow. I never imagined it to be fast. It has multiple layers of abstraction and does lots of checks. A custom solution giving the same level of detailed type safety wouldn’t be fast either.
Software just got very complex. Data became larger. And sometimes you better don’t implement abstractions to reach at least some efficiency with all these petabytes of 8k cat pictures and tiktoks…
Zod surely is slow. I never imagined it to be fast. It has multiple layers of abstraction and does lots of checks. A custom solution giving the same level of detailed type safety wouldn’t be fast either.
Software just got very complex. Data became larger. And sometimes you better don’t implement abstractions to reach at least some efficiency with all these petabytes of 8k cat pictures and tiktoks…
I think once the complexity goes up to a certain point, there is no way to fix performance by throwing more programmers to the caldron.
Look in the mirror.
You are describing yourself, because you chose convenience over having to look for better alternatives.
And there are plenty.
You are describing yourself, because you chose convenience over having to look for better alternatives.
And there are plenty.
Agree. So your rust based terminal ("a modern, Rust-based terminal with AI built in"???) is resource hungry - go use xterm then? VSCode too heavy - have all the other lighter editors disappeared?
This strikes me as wanting the features but not the cost. Could the features have been implemented better? Maybe - but no-one's paying for that so enjoy your featureful, free, and bloated VSCode.
This strikes me as wanting the features but not the cost. Could the features have been implemented better? Maybe - but no-one's paying for that so enjoy your featureful, free, and bloated VSCode.
You mean why are programmers lazy? Oldest question in compsci my friend.
The answer is because it’s efficient.
The answer is because it’s efficient.
Convenience saves developers time, which is the most valuable resource in a company.
Cue Stanford complaining about 64 H100s…
Everybody knows that Real Programmers™ rely on the incredible raw performance of plain Typescript, not fancy libraries /s