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.
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.
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.
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.
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.
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.
Don't do the reverse
Your way of saving memory will keep me up at night.
We're not in the rocket launching business. Desktop memory is cheap and nodejs/electron makes it easy to develop cross platform.
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…
You are describing yourself, because you chose convenience over having to look for better alternatives.
And there are plenty.
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.
The answer is because it’s efficient.
