3 ms·

We've also benefitted from moving from a monolith to SOA-esque services. IMO, The thing that DHH is failing to mention is that Monoliths work great when your a

We've also benefitted from moving from a monolith to SOA-esque services. IMO, The thing that DHH is failing to mention is that Monoliths work great when your application looks something like Basecamp. Basecamp, while a great tool, is a "simple application". I don't mean it's not well built, I don't mean it's easy to build, I don't mean it was fast to build, but if you look at what it does, it's all vanilla stuff. Many other companies don't have the luxury of building apps that look like basecamp, and hence, our architectures are more complex. When he writes these kinds of articles, they always feel somewhat strawman-ish. At the end of the day, each software project has it's own unique requirements that will govern success. We got paid the nice salaries we do because it is up to our discretion to understand what is the most efficient architecture for what we are trying to solve.

benjismith 11y ago
Just curious what you mean by "if you look at what it does, it's all vanilla stuff". What would "non-vanilla stuff" look like? It's all just code, right?
- eric_h 11y ago
  I think he means "all the things that Rails handles well with default options/configurations"
- erichmond 11y ago
  If you look at their feature list (https://basecamp.com/3/features https://basecamp.com/3/features) you see: - Message boards - comment threads. - Real-time chat/pings. - Automatic check-ins. - To-do lists. - Docs & file storage. - A centralized schedule Everything in this list sans real-time chat I would consider as low complexity, low volume and low velocity. It's basically request a view, hit a cache / db, display some data. Send an email now and again. Store some stuff on s3 now and again. There are lots of sites that have more complex feature sets then what basecamp does. Things like complex transcoding of media, real-time updates on their views, streaming of complex media types, need for near-real-time integration with 3rd party APIs, real-time bidding, real-time decision making, real-time analytics, etc etc etc. I want to be very clear that I am not criticizing Basecamp as a product. Simplicity is difficult to achieve in software and their product does a great job of doing most of what you need, and not much else. I based the software stack of the first company I founded on pre-1.0 rails monolith (mongrel had just been released), so I'm not even anti-monolith. I just think this particular post of his is entirely too simplistic and could lead younger software designers astray.
  - goldbrick 11y ago
    Real-time chat isn't even that complex, especially now that Rails has ActionCable.
ryanbrunner 11y ago
That's a fair point, and for sure there are problems that demand a more complex approach. What I do sometimes see as a problem is that people assume that their app necessarily needs to be more complex than Basecamp, and that arguing for simplicity and "plain old CRUD" approaches to problems is an impossible task. The best way to manage complexity in a lot of cases is to reject the complexity in the first place. That's not always feasible, but there's a real cost to complexity even when well-managed, and if a "simple application" approach can deliver the same or even 80% of the value, it's often a trade-off worth making.
- erichmond 11y ago
  These days I code in immutable, functional, objectless clojure for the most part, so I'm with you 1000% on reducing complexity. The easiest line of code to maintain is the one that doesn't exist. :)
stefano_c 11y ago
> The thing that DHH is failing to mention is that Monoliths work great when your application looks something like Basecamp. The thing that people fail to grasp is that (almost) everything DHH writes is in the context of "when your application looks something like Basecamp" :-) I've been following 37signals/Basecamp since 2002, I think (long before Rails) and they've always made it clear that their opinions/advice are _not_ universal, because they only speak from experience - _their_ experience. So, if you're not in a similar situation as theirs, then of course their arguments are going to look strawman-ish to you.
- 0xCMP 11y ago
  And while he does that to excuse himself from having to reiterate that later, the fact that he doesn't anyways leaves a reader by the end thinking "Damn, maybe he's right. Maybe all software should be this way." even when it shouldn't.
- jrochkind1 11y ago
  > ...they've always made it clear... Always? How about in the OP?

benjismith 11y ago

Just curious what you mean by "if you look at what it does, it's all vanilla stuff". What would "non-vanilla stuff" look like? It's all just code, right?

eric_h 11y ago
I think he means "all the things that Rails handles well with default options/configurations"
erichmond 11y ago
If you look at their feature list (https://basecamp.com/3/features https://basecamp.com/3/features) you see: - Message boards - comment threads. - Real-time chat/pings. - Automatic check-ins. - To-do lists. - Docs & file storage. - A centralized schedule Everything in this list sans real-time chat I would consider as low complexity, low volume and low velocity. It's basically request a view, hit a cache / db, display some data. Send an email now and again. Store some stuff on s3 now and again. There are lots of sites that have more complex feature sets then what basecamp does. Things like complex transcoding of media, real-time updates on their views, streaming of complex media types, need for near-real-time integration with 3rd party APIs, real-time bidding, real-time decision making, real-time analytics, etc etc etc. I want to be very clear that I am not criticizing Basecamp as a product. Simplicity is difficult to achieve in software and their product does a great job of doing most of what you need, and not much else. I based the software stack of the first company I founded on pre-1.0 rails monolith (mongrel had just been released), so I'm not even anti-monolith. I just think this particular post of his is entirely too simplistic and could lead younger software designers astray.
- goldbrick 11y ago
  Real-time chat isn't even that complex, especially now that Rails has ActionCable.

ryanbrunner 11y ago

That's a fair point, and for sure there are problems that demand a more complex approach. What I do sometimes see as a problem is that people assume that their app necessarily needs to be more complex than Basecamp, and that arguing for simplicity and "plain old CRUD" approaches to problems is an impossible task. The best way to manage complexity in a lot of cases is to reject the complexity in the first place. That's not always feasible, but there's a real cost to complexity even when well-managed, and if a "simple application" approach can deliver the same or even 80% of the value, it's often a trade-off worth making.

erichmond 11y ago
These days I code in immutable, functional, objectless clojure for the most part, so I'm with you 1000% on reducing complexity. The easiest line of code to maintain is the one that doesn't exist. :)

stefano_c 11y ago

> The thing that DHH is failing to mention is that Monoliths work great when your application looks something like Basecamp. The thing that people fail to grasp is that (almost) everything DHH writes is in the context of "when your application looks something like Basecamp" :-) I've been following 37signals/Basecamp since 2002, I think (long before Rails) and they've always made it clear that their opinions/advice are _not_ universal, because they only speak from experience - _their_ experience. So, if you're not in a similar situation as theirs, then of course their arguments are going to look strawman-ish to you.

0xCMP 11y ago
And while he does that to excuse himself from having to reiterate that later, the fact that he doesn't anyways leaves a reader by the end thinking "Damn, maybe he's right. Maybe all software should be this way." even when it shouldn't.
jrochkind1 11y ago
> ...they've always made it clear... Always? How about in the OP?