4 ms·

> I really like web apps that are just CRUD forms. I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure

> I really like web apps that are just CRUD forms. I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.

searls 2y ago
As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business. There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive. I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it. IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender. Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
- andrei_says_ 2y ago
  Similar experience here. I see unnecessarily overengineered SPAs everywhere - from blogs to CRUD-only SAAS and read about devs starting each project as an SPA by default. Including blogs and static websites. The choice to spend 10x-50x the resources and deal with the agony of increasing complexity doesn’t make sense to me. Especially in the last few years since Rails’ Hotwire solves updating page fragments effortlessly.
- globular-toast 2y ago
  I'm not sure I'm following what you're saying here. Are you saying that, ultimately, everything boils down to CRUD? Like how humans are really just a very elaborate chemical reaction? Or are you saying businesses are literally CRUD? As in you can charge money to create database records? Of course everything is just CRUD. That's all a database can do. But writing every piece of software at that level is insanity. When I say pure CRUD I mean software that is literally just a thin veneer over a database. Now that actually is useful sometimes but generally you'll want to be able to write higher level abstractions so you can express your code in a more powerful language than CRUD. Are you really saying you've consulted for businesses that just do CRUD? As in they have meetings about creating, updating and deleting database records?
nlitened 2y ago
I actually believe that most of useful real-world software is “one step away from Excel”, and that’s fine
- globular-toast 2y ago
  I think it's two steps away from Excel. The first step is making schemas explicit and doing normalisation to avoid data anomalies. This is where RoR gets you. The second step is naming the operations/use cases in your business/domain (preferably with words people already use) rather than trying to frame everything as CRUD operations.

searls 2y ago

As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business. There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive. I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it. IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender. Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.

andrei_says_ 2y ago
Similar experience here. I see unnecessarily overengineered SPAs everywhere - from blogs to CRUD-only SAAS and read about devs starting each project as an SPA by default. Including blogs and static websites. The choice to spend 10x-50x the resources and deal with the agony of increasing complexity doesn’t make sense to me. Especially in the last few years since Rails’ Hotwire solves updating page fragments effortlessly.
globular-toast 2y ago
I'm not sure I'm following what you're saying here. Are you saying that, ultimately, everything boils down to CRUD? Like how humans are really just a very elaborate chemical reaction? Or are you saying businesses are literally CRUD? As in you can charge money to create database records? Of course everything is just CRUD. That's all a database can do. But writing every piece of software at that level is insanity. When I say pure CRUD I mean software that is literally just a thin veneer over a database. Now that actually is useful sometimes but generally you'll want to be able to write higher level abstractions so you can express your code in a more powerful language than CRUD. Are you really saying you've consulted for businesses that just do CRUD? As in they have meetings about creating, updating and deleting database records?

nlitened 2y ago

I actually believe that most of useful real-world software is “one step away from Excel”, and that’s fine

globular-toast 2y ago
I think it's two steps away from Excel. The first step is making schemas explicit and doing normalisation to avoid data anomalies. This is where RoR gets you. The second step is naming the operations/use cases in your business/domain (preferably with words people already use) rather than trying to frame everything as CRUD operations.