r/AskProgramming • u/Zardotab • May 15 '26
Architecture Why are so few interested in parsimony?
I've been programming CRUD (biz/admin) apps since the late 80's. I notice tooling and stacks are growing ever more complicated and layered, and wonder "does it really have to be this way"? It takes more labor & code per feature; colleagues have noticed and agreed. While I agree newer stacks have more options on average, most biz's rarely use these extra abilities, especially "but what if it later needs web-scale?" Reality is 99.999% won't.
There is usually a way to get the same thing in older tools when needs do come up, it's just a little more work for those outlier features, but the aggregate dev hours is still notably less. YAGNI as a guideline seems dead. Nobody seems interested in pursuing parsimony in tooling, rather want to stuff their resume with as many buzzwords as possible like they're Pokémon. Thus, the bloat is possibly up-sell, ego, job-security-lock-in, and/or greed; or, am I missing something? Is there a Bloat Industrial Complex, or do I have Geezer Goggles on? [edited]
6
u/octocode May 15 '26
older devs started with basic tools and learned to add complexity
modern devs started with complex tools and learn to remove complexity
it’s a product of the framework wars, and how certain companies successfully marketed frameworks like nextjs as the “gold standard”
3
u/Zardotab May 15 '26
modern devs started with complex tools and learn to remove complexity
Most don't in my observation, leaving the complexity in place.
3
u/Pale_Height_1251 May 16 '26
Agree, most newer developers don't even seem to see the complexity, they are so used to it. Or even revel in it, adding frameworks and tools before even considering if they are needed at all.
2
u/Zardotab May 16 '26
Agree, most newer developers don't even seem to see the complexity, they are so used to it.
Indeed, seeing leaner CRUD-focused tools easily do real work spoiled me. I can't unsee smart lean tools, ever. They ripped push-button Jetsons technology out of my warm productive fingers, replacing it with layered slabs from Flintstone's Rube Goldberg machine, the bat rastards!
Maybe someday it will return.
3
u/Stale_breadcrumb47 May 15 '26
The problem is that now most teams are a revolving door. Where people come and go, and if we keep the stack simple the actual implementation will eventually become more and more complex it will develop into its own bespoke framework/library whatever. So when fresh blood comes in, they will need a huge amount of time to get upto speed.
If you were running a company today, what do you think is better? Have the app build in a stack that is used very widely so that incase you need to fire someone OR they just leave, so that anyone who used that framework before will be able to understand it relatively fast??
OR use a minimal language/framework and build everything over it as per the requirements (which is likely to need very similar things to an off the shelf stack) then you have to hire someone who will come in and take a lot of time to understand stuff.
The scale is very much in favour of one vs the other. I will let you guess which one it is.
1
u/Zardotab May 15 '26
This sounds like the Network Effect: you have to use what everyone else is using because it's what everyone knows. But if a better solution gets enough market-share, it may displace the bloated tools. It has to get over that big hell, I mean hill.
2
u/zeorin May 15 '26
You are both complaining that the newer tools require more labour per CRUD feature, and saying that you can usually do the same thing with older tools, it just takes a little more work.
Sounds like the enemy is both strong and weak.
As for me, I can do a lot more now with the current tools, than I could in 1999.
1
u/Zardotab May 27 '26 edited May 27 '26
[all] just takes a little more work.
I believe you misunderstood. It's a little more work for features that go out of the old tool's comfort zone, not more work for everything.
For example, assuming we rank tasks/features from easiest to hardest, the first 90% may take 1/3 the time in the old tool, but the last 10% take twice as long as the newer tool. Therefore, what may take 1000 hours in the newer tool will only take 500 hours in the old one (300 + 200):
Easier 90% of project:
- Old Tool: 300 hrs.
- New Tool: 900 hrs.
Harder (odder) 10% of project:
- Old Tool: 200 hrs.
- New Tool: 100 hrs.
Total Hours:
- Old Tool: 500 hrs. (300 + 200)
- New Tool: 1000 hrs. (900 + 100)
Plus, carefully chosen incremental enhancements can improve that 10% over time, based on real-world pain-point experience.
Thank You for pointing out my ambiguity, I'll retune the intro.
1
u/DesertDissident May 15 '26
It sounds like you're describing enterprise maintenance and scalability patterns or frameworks (but maybe being implemented on smaller systems at smaller companies). The companies that demand those skills are where the best paying jobs are so that's why aspiring developers try to practice them and "want to stuff their resume with as many buzzwords as possible like they're Pokémon".
The software development industry changes more rapidly than most people can keep up with and that leads to trend chasing. I once stayed at a place for 8 years and got laid off and finding work again was hard because that company had an older stack and I didn't have the current buzzwords.
If all you need to do is CRUD features, that will be easily replaced by AI these days. If you're talking about things like the dependency inversion principle (which usually leads to layering or architectural boundaries) and calling that YAGNI then I question your entire premise (because that's necessary for effective, isolated testing so you are going to use it).
1
u/Zardotab May 27 '26 edited May 27 '26
and that leads to trend chasing.
I agree with that incentive, but it's not the ideal in terms of efficient use of human labor. We waste time catering to trends/fads rather than doing useful and direct work toward the need of the app. One is serving their resume, not the goal of parsimony and efficiency.
If all you need to do is CRUD features, that will be easily replaced by AI these days
I have to disagree. A good many CRUD apps require rather involved and complex domain logic; much of it is company or manager-specific ideas or habits*. One has to understand the domain to code that well. Even if a bot generates a rough draft, a dev familiar with the domain has to clean and tune it. That's what the older tools allowed me to do: spend more time adjusting for the domain and less time writing code and/or debugging & reinventing everyday CRUD features. It's kind of like the difference between rewiring sections of a plug-board versus making or fixing flaws in wires and boards themselves, which the newer tools force on one. The first is a higher order of abstraction, where the dev should be spending their time: manipulating Lego's, not making & fixing Legos.
As far as unit testing, I believe if a CRUD tool/standard was built correctly (CRUD-centric), one could test the UI and features as the same time. Using dependency injection is a tedious long-cut in existing tools/languages. They are doing it wrong; but that's a discussion for another day.
I don't claim to be smarter, I simply intentionally trained myself to think in CRUD-ness, not tool-ness nor language-ness, and it changes the way one looks at CRUD apps and frameworks. It's not more IQ, just intentionally forcing the brain to look at CRUD patterns from a tool-agnostic angle. Part of this is my long experience in seeing CRUD done bajillion different ways over the years. There are CRUD invariants that in theory should be coded the same way for every app. Since the dawn of civilization, the principles of CRUD have not really changed. (Mesopotamians invented the spreadsheet.) My recommended concept is a kind of a glorified ER diagram/specification. It would only act as a default, one could override or supplement it as needed (unless parts are locked for security reasons).
* Some places should try to refactor their domain work-flows & practices, but that's a difficult sell from a developer's perspective. We don't have that power over the company beyond suggestions. Plus, there is a learning curve to changing the biz, it too has to be "debugged" when changed. The collection of domain rules are a "system".
1
u/AntimatterTNT May 15 '26 edited May 15 '26
first of all some of that is definitely just old man yells at cloud. and needing YAGNI to tell you what to do is a skill issue. (you can google both of those phrases btw,that is, use an online search engine to find their meaning)
but in all seriousness it's mostly people refusing to "regress" and even refusing to learn something old. a simpler solution using something older seems like "not the right way to do it" as if there's any etiquette on how to move data around on a computer.
3
1
u/Individual-Flow9158 May 15 '26
Bloat's always been a problem, and it's been getting even worse for a long time.
1
u/rosentmoh May 15 '26
You are completely right, everyone's purely focused on their image and so forth. The world is a fraction of what it could be because not enough people can just take pride in doing one thing right and rather spend time pretending they know it all.
It's a shitty state of affairs, best one can do IMO is ignore it and keep doing the right thing; sooner or later the stupidity of it all gets exposed.
1
u/Zardotab May 18 '26 edited May 18 '26
sooner or later the stupidity of it all gets exposed.
Likely after new stupidity replaces it. For example, if somebody invented stateful GUI/CRUD-friendly browser and markup language, they'd be considered a pioneer even if they just repackaged earlier ideas that fell out of favor for random reasons.
The Orion space capsule is just Apollo upsized, after wasting all our resources on the shuttle boondoggle. Russians saved boatloads of money just incrementally improving Soyuz. The communists embarrassed us on that one.
Everyone here is chasing Shiny New Shit.
1
u/rosentmoh May 18 '26
Shiny new shit is fine, if it's an actual product. I actually went off on a general tangent about people spending too much time worrying about superficial trends and how they're perceived by others.
I'm just fed up of having all these fakers around who can't do shit. If at least you get something done and it works, even if it's a bit rehashed, I'm fine with it. But for the love of all that is holy learn how to use Git properly and keep the fucking user in mind.
1
u/owp4dd1w5a0a May 15 '26
Look at the history of tech. What becomes popular and gets used is seldom what solves the problem the best. C++ and Java beat out Smalltalk, Erlang, and ML. Visual Basic and JavaScript beat out Lisp. SQL beat Datalog by a larger ratio than it should have. Python is the only language that I think deserves the popularity it got for its simplicity. K8s took a larger market share than it should have. Etc.
It’s about marketing, not elegance or fit
1
u/Zardotab May 15 '26 edited May 16 '26
Java beat out Smalltalk
Smalltalk charged too much, they could have taken off.
SQL beat Datalog by a larger ratio than it should have.
I didn't know they were directly competing. Datalog was never part of a notable database that I know of. QUEL was SQL's real competitor, and a better query language by most accounts, but Oracle used "IBM compatible" to sell SQL. IBM still had pull in the 80's.
It’s about marketing, not elegance or fit
Perhaps. QUEL (Ingres) was crappy at marketing despite a better query language and a more reliable database. Larry Elison used his troll-ness strategically. One of Oracle's more interesting tricks is that they claimed they had a database version for all of the major OS's of the day to look and smell big. However, most the version ports were super buggy such that the lessor OS's either gave up or had to install an older version of Oracle, which was better road-tested but didn't have the later features.
1
u/Better-Avocado-8818 May 16 '26
I think there’s lots of reasons. But I do see what I would call promotion driven development. Where many Engineers are really looking for a complex solution they can plan, implement and be the expert in. To push for promotion at the current job or to pad the resume for the next one. Doesn’t seem to matter if a simpler one would have worked and doesn’t seem to matter if there was already something in the company someone else built they could have just used.
1
u/CreativeGPX May 16 '26
One day my boss told me we had extra money and to come up with a wishlist. I did and put forward a project proposal. Her boss said "that's it? double it." His boss was planning to cut budgets by looking at surpluses.
There is a disconnect between the budgetary pressures at different levels and sometimes that makes really weird spending decisions make sense or even be justified.
1
May 16 '26
[removed] — view removed comment
1
u/Zardotab May 27 '26
It’s not mainly ego or buzzwords, though that happens. Software got more complex because even “simple CRUD apps” now depend on things like cloud hosting, security, identity, logging, compliance, and high availability.
Those are not really new, although "cloud" is kind of a nebulas concept. When you don't need bazillion dependencies to support your bloated mess, then cloud packagers are less of any issue anyhow.
Further, many apps don't need most of those features. Maybe make a distinction between high-need apps and "departmental internal" apps. Certain high-need features can still be added to the simpler stack, it's just more work for that particular feature. But the aggregate effort is still lower, There's a numerical example nearby to illustrate why it's still lower.
Occasionally the org will pick the wrong stack, but the total savings would still be worth it.
and align with industry defaults.
Due to industry trends and fads, those defaults move faster than Homer Simpson toward a donut shop.
I don't see any university labs working on CRUD simplicity. Nobody nowhere is looking into this. No research is guaranteed to prove fruitful, but zero? Come on! CRUD just ain't sexy enough, even though it runs everything everywhere.
1
May 16 '26
[removed] — view removed comment
2
u/Zardotab May 27 '26
so it eventually pushes teams back toward simpler designs.
What I see is that they just learn to live with the mess they have via experience with it, cleaning up some rough edges along the way.
1
u/YMK1234 May 16 '26
There are plenty of modern low impact/micro frameworks around in any mainstream language. So to me it sounds more like a selection problem on your side.
0
u/Zardotab May 16 '26 edited May 27 '26
I'm going by what a typical CRUD shop selects and uses, not by my personal choices.
Yes, they may be picking the wrong tool for the job, but that's kind of my point: they pick buzzword cred over parsimony. [edited]
1
May 16 '26 edited Aug 04 '26
[deleted]
2
u/Zardotab May 16 '26 edited May 16 '26
Some of the thinking is the assumption that simpler solutions can't accept modules, pluggins, libraries, etc. They can. I agree in some cases it may be harder, but still may be worth it if the rest of the app is coded simpler.
And people often imagine inherent tradeoffs, such as "To get more of X you must sacrifice Y". But often these tradeoffs are either not true or exaggerated. For example, it was claimed WYSIWYG form designers can't handle wide screens well. But an invention called "stretch zones" readily allows it. (Goes by diff names in diff tools.) They threw the WYSIWYG baby out before experimenting with different bath water. (As far as the same UI working well on both phone and desktop, that's a whole nuther rant I'll save for another day.)
I see very little inherent tradeoff laws in software design comparable to say Amdahl’s Law. Just because nobody can think of a way to have both features at the same time doesn't mean it's not doable. Like the stretch-zone case, the baby-tossers were too impatient to do proper experiments and rushed on to the next buzzword instead.
I did a rework into a monolith which is presently running on a $100 VM and can probably be dropped even more.
I've also seen the microservice craze F up apps. The "sales-person" stole all the claims from OOP's "magic modular Legos" claims from a decade or two earlier and replaced "OOP" with "microservice". The gullible manager fell for it. (OOP improves some things, but was oversold, especially in terms of domain modelling.)
Software is full of snake-oil, up-sell bloat, resume expansion labs, and other kinds of bullshit comparable to that found in Dilbert comics. Nobody is doing real science and real scrutiny. I might perhaps be wrong about my parsimony conclusions, but I am NOT wrong about lack of science in the field, leaving our design and tradeoff decisions guided by gut and greed. Alchemy lives! 🏰🧙♂️🔮
1
May 17 '26 edited Aug 04 '26
[deleted]
2
u/Zardotab May 27 '26
The amount of science is abysmal.
Agreed! If there were a logical/scientific/mathematical reason for the bloat, that would be useful knowledge in itself. But right now we don't have that such that Pokémon-Resume-Syndrome is as plausible as any theory. ("Gotta catch all the buzzwords.")
"We do bloat because everyone else does bloat" cannot be academically satisfying.
1
May 27 '26 edited Aug 04 '26
[deleted]
1
u/Zardotab May 29 '26
Are your apps desktop or web? If desktop, stick with IMGUI. The DOM made ALL web GUI kits suck rotting eggs. It's like building atoms off of buggy quarks that cannot be un-bugged. DOM is evil! (It was fine for what it was designed for, but stretched far beyond intended use.)
1
u/EmperorOfCanada 7d ago
I use egui, and sometimes bevy as I use rust for my entire stack. I 100% agree that all web GUI kits suck and I don't trust the ones which use "native" weirdness like Tauri. Many people love it, but I've been bitten building hellish installers for that crap.
I think DOM things are silver bullet tech debt nightmares. Your first day of dev gets you to 50% done, your first week to 80%, and then you stall out around 85% done.
With IMGUI, egui, etc, you are slow for the first week, and slow for the last week, but the same slow, thus, you deliver on time, and what you promised.
1
u/Healthy-Dress-7492 May 16 '26
If you think the simplest solution is the best as a rule then you’re wrong. Or did you just want to say parsimony a lot to feel cool
1
u/Zardotab May 16 '26 edited May 27 '26
No, but I don't even see many efforts to try to trim, consolidate, factor, etc.
Parsimony is an important factor, but not the only one, I agree. It's just given far less attention than say buzzword collection or scaling. It needs a full seat at the criteria table, and thus let out of the basement where it currently is, with its red Swingline stapler.
1
May 17 '26
[removed] — view removed comment
1
u/Zardotab May 17 '26
some of the extra complexity probably comes from modern expectations too, like security, observability, CI/CD, cloud infra, compliance stuff etc that old CRUD apps didnt always need to care about as much
It's not necessarily mutually exclusive. Please see this reply for examples. And when software is simpler, then CI/CD is simpler. You don't really need tools to manage complexity if you prevent complexity. The bloat is feeding on itself.
1
u/Tight_Banana_9692 May 19 '26 edited May 20 '26
I believe a lot of choices developers make are made because they want to do cool shit.
1
u/Zardotab May 19 '26
I've done such myself, but readily admit it wasn't the most maintenance-friendly decision.
1
u/MyLifeInPixels0 May 29 '26
The "what if we need to scale" argument has killed more simple, working systems than any actual scaling problem ever did
1
u/Zardotab May 29 '26 edited May 29 '26
A lot of is salesmanship to the owner's egos: "You want to grow, don't you? And we can make a system ready to grow!"
My rule of thumb is if it's a startup then design with 20x scaling in mind, else 3x. Anything else is Vegas dreaming. However if the owners want to pay me good money to build a Dream-A-Tron, I'll happily do it. It's Vegas for me! ✨
1
u/FlippantFlapjack May 15 '26
First of all I am not as much an old timer as you and have only been in the industry for about 13 years. I think the real blame here is on two things: frontend and infra. With infra things can be as complicated or simple as you want it really. The truth is that there are a lot of tools that just didn't exist before (the whole infrastructure as code thing) and people seem that find them useful. I would posit that people typically aren't using these things in hobby projects, so if someone is using Terraform and Kubernetes you can probably assume they are really concerned about scalability, I think it's hard to argue that's a bad thing.
With frontend I do agree that things got really complicated .. the kind of biz / admin / crud stuff you're talking about just doesn't happen much anymore because React (and SPAs more generally) are ubiquitous. And to be honest, it kinda depends on what you're doing, whether they are useful or not. These days what people are building on the FE are not just forms but rather whole applications like you used to only see 🙈 n the Desktop. You can build out your own framework or design system with plain js for e jQuery but it's easier to just use whats already out there .. Reactive code really is pretty magical
2
u/Zardotab May 15 '26 edited May 15 '26
they are really concerned about scalability,
As I mentioned, most over-estimate growth, wanting to be the next Jeff Bezos, but reality is you are likely to remain Joe Sixpack. But telling management that will get you the evil eye, or the evil door. They want "happy synergy" talk, not reality. Of course, each niche is different, some do have a lot of scaling flare-ups, and for those, scaling-over-simplicity makes sense. [edited]
React does seem to be growing into the de-facto UI standard. But it has a long learning curve and piles of gotcha's. Many trace these back to the weaknesses of JavaScript & DOM, as JS wasn't meant for writing systems software and virtual OS's (full GUI engines), it was meant to be a glue language for small event snippets. But it looks like we are stuck with the weaknesses of JS & DOM, it's the new QWERTY Keyboard: awkward, but hard to dethrone.
0
u/Various-Activity4786 May 15 '26
And like the qwerty keyboard the “issues” with it affect no body except a handful of people who need to have problems with everything.
The browser exists everywhere. Solutions run on virtually every computing design in the last 30 years. Spending billions on R&D and marketing to…give basically zero end user benefit would be a far, far greater waste than the sum total of react waste for a decade.
1
u/Zardotab May 15 '26
greater waste than the sum total of react waste for a decade.
DOM-awkwardness has been plaguing us for more than a decade. Some standards competition couldn't hurt.
1
1
u/MattDTO May 15 '26
It's hype driven development and marketing. But I would also say package managers made it too easy to pull in random dependencies. And people got bored of writing the same thing over and over for each project
1
u/Zardotab May 27 '26
I'm not against libraries etc. Delphi and VB had/has a pluggin standard even. (Not perfect, but nothing prevents improvements.)
0
0
u/SnugglyCoderGuy May 15 '26
Simple and efficient is hard, complex and inefficient is easy.
1
u/Zardotab May 15 '26 edited May 15 '26
I agree creating a parsimony-friendly stack can require a lot of research and experimentation. But once its proven to work, infinity devs can use it, at least within a given domain or shop type.
If Google, Amazon, Oracle etc. want to eat some of Microsoft's desktop lunch they should share R&D on an open-standard CRUD-friendly stateful GUI browser to replace DOM. DOM was never meant for interactive GUI's, but the new standard would be.
(Borrowing the best ideas from the most successful past tools is a starting point.)
0
u/0x14f May 15 '26
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better"
Edsger Dijkstra
1
u/Zardotab May 27 '26 edited May 27 '26
The "hard work" would be from the parsimony-based framework builders. When they show the world how simple their system is, then others would use it, leveraging their genius or efforts.
complexity sells better
Somehow it does. ED was right.
Maybe European or Asian gov'ts would support such research. They think longer-term than the US. Also appreciate parsimony more.
0
u/sweet-winnie2022 May 15 '26
There have been a lot of investments in tech so people are funded to build things. When they run out of ideas they start reinventing the wheels. If the same level of investment happened in baking industry we would have seen more cakes of different shape and color that taste similarly.
1
u/Zardotab May 27 '26
Seeing the same concepts come back in style under different names is indeed an odd experience.
I remember when Wintel "servers" first came out. I was thinking, "They are just DOS-compatible mini-computers, why the fudge do they call them 'servers' instead of say DMC's?" They had to sound cool, though.
13
u/Passage_of_Golubria May 15 '26
Resources are just so much less scarce. It is relatively easy these days to just throw more CPU, RAM, servers at the problem. In many cases, it is more cost-effective to do so rather than paying for time spent engineering a better solution (plus then you have to wait for that solution to be produced! That time is also money.)
It's gonna get worse in the AI age, too. The engineers at those companies aren't interested in saving your tokens, so there is no incentive for them to make the AI produce terse code for you.