4 ms·

I feel like MVC is being treated as like the one true pattern to design your web app with and that's just simply not true. Rails is MVC and maybe that's all it

I feel like MVC is being treated as like the one true pattern to design your web app with and that's just simply not true. Rails is MVC and maybe that's all it should be for what it is intended for. Other projects might not be a great fit for such a simplistic view of the world and maybe that means Rails is not a great fit for projects that don't fit into the MVC abstraction. In my experience MVP, MVVM, super thin Sinatra API's, hexagonal architecture, functional programming, and other sort of weird approaches fit certain projects much better than the standard Rails MVC approach. Also, not every project is a web app and there are plenty of times where various testing approaches make a lot more sense than they do in Rails. It's too bad that a whole line of thinking about software quality is being disparaged because it isn't a good fit for Rails as DHH sees it. TDD is a useful tool in the right context. Maybe that context isn't Rails. It seems unwise to be telling a lot of smart people who care about software quality to "get off my lawn" so to speak, but I've never run a successful OSS project as big as Rails, so I probably don't have a clue about how to lead a community as big as Rails is.

ryanbrunner 12y ago
I think one important thing to keep in mind is that TDD is not necessarily synonymous with "software quality". In some cases it's a very useful tool to ensure the quality of your code, but it's not even the stated goal of TDD, and a focus on TDD as the "one true path" to software quality ignores that some things are more effective (not necessarily simpler) to test using more of a "test later", integration-focused testing approach. I agree that there's projects where a simplistic MVC approach doesn't completely fit. That doesn't mean that every software project needs to be built to the standards of the most complex software, or even that aspects of a project that do require this complexity can't be solved with a more straightforward, simple MVC approach. At the end of the day, I think the main message I get from DHH's recent series of blog posts is that treating anything as a silver bullet, or a universally beneficial pattern is harmful - and this is equally as applicable to MVC for everything itself as it is for a complex, hexagonal architecture.
- cwbrandsma 12y ago
  Bad programmers will write bad code no matter the methodology, pattern, language, tooling, or best practice.
  - mwcampbell 12y ago
    That's not useful though. What makes programmers bad? In some cases, at least, it's the methodology, patterns, or best practices they use.
    - collyw 12y ago
      More often than not it is lack of any methodology, patterns or best practices.
jshen 12y ago
You have it backwards. TDD advocates are the ones claiming that their way is the one true way, that all software should be done their way. Edit: I'm not sure why I'm getting downvoted. Here's a quote from Bob's post that was linked yesterday which shows what I'm talking about > If you aren't doing TDD, or something as effective as TDD, then you should feel bad.
- kasey_junk 12y ago
  That quote specifically says there isn't "one true way". You are ignoring the "something as effective as TDD" in the middle of it.
  - jshen 12y ago
    I'd love for him or you to give me an example of an alternative that I should't "feel bad" about.
    - kasey_junk 12y ago
      I've used software contracts in conjunction with automated tests written after the fact to good result. I didn't find it any better than TDD and in some cases my outcomes were worse (but I expect that was my inexperience with the development mode).
      - jshen 12y ago
        if you write them after the fact you aren't doing TDD or something as good as TDD. At least, this is what the TDD mob says.
        kasey_junk 12y ago
        For nearly any realistic definition of "TDD mob" you can name, I'm in it. If your process results in well factored, automatically verified code that let's me refactor mercilessly, than its as good as TDD. In my experience I'm not disciplined enough to do this & most other developers aren't either. I've encountered far more untested code bases in my life than TDD zealots.
SoftwareMaven 12y ago
This comment feels orthogonal to TFA (but it makes a great strawman). The author was using rails apps as an example of how to think about testing and design, not laying out the one true path to software development. Whether it is a rails web app or a functional high frequency trading app, the author's point stands: don't let dogma dictate your testing strategy at the expense of harder to read, nastier to maintain code.
noir_lord 12y ago
MVC (like all good tools) has it's place. Shoehorning everything into MVC because it's the "one true way" is where the problems arise. My current system uses Controllers, Views, Services and Repositories with ORM objects as the "entities" (it's based on Laravel/Eloquent) and I've found that to be an acceptable trade off for the domain I'm modeling, MVC would have been painful when you have a lot of business logic.

ryanbrunner 12y ago

I think one important thing to keep in mind is that TDD is not necessarily synonymous with "software quality". In some cases it's a very useful tool to ensure the quality of your code, but it's not even the stated goal of TDD, and a focus on TDD as the "one true path" to software quality ignores that some things are more effective (not necessarily simpler) to test using more of a "test later", integration-focused testing approach. I agree that there's projects where a simplistic MVC approach doesn't completely fit. That doesn't mean that every software project needs to be built to the standards of the most complex software, or even that aspects of a project that do require this complexity can't be solved with a more straightforward, simple MVC approach. At the end of the day, I think the main message I get from DHH's recent series of blog posts is that treating anything as a silver bullet, or a universally beneficial pattern is harmful - and this is equally as applicable to MVC for everything itself as it is for a complex, hexagonal architecture.

cwbrandsma 12y ago
Bad programmers will write bad code no matter the methodology, pattern, language, tooling, or best practice.
- mwcampbell 12y ago
  That's not useful though. What makes programmers bad? In some cases, at least, it's the methodology, patterns, or best practices they use.
  - collyw 12y ago
    More often than not it is lack of any methodology, patterns or best practices.

jshen 12y ago

You have it backwards. TDD advocates are the ones claiming that their way is the one true way, that all software should be done their way. Edit: I'm not sure why I'm getting downvoted. Here's a quote from Bob's post that was linked yesterday which shows what I'm talking about > If you aren't doing TDD, or something as effective as TDD, then you should feel bad.

kasey_junk 12y ago
That quote specifically says there isn't "one true way". You are ignoring the "something as effective as TDD" in the middle of it.
- jshen 12y ago
  I'd love for him or you to give me an example of an alternative that I should't "feel bad" about.
  - kasey_junk 12y ago
    I've used software contracts in conjunction with automated tests written after the fact to good result. I didn't find it any better than TDD and in some cases my outcomes were worse (but I expect that was my inexperience with the development mode).
    - jshen 12y ago
      if you write them after the fact you aren't doing TDD or something as good as TDD. At least, this is what the TDD mob says.
      - kasey_junk 12y ago
        For nearly any realistic definition of "TDD mob" you can name, I'm in it. If your process results in well factored, automatically verified code that let's me refactor mercilessly, than its as good as TDD. In my experience I'm not disciplined enough to do this & most other developers aren't either. I've encountered far more untested code bases in my life than TDD zealots.

SoftwareMaven 12y ago

This comment feels orthogonal to TFA (but it makes a great strawman). The author was using rails apps as an example of how to think about testing and design, not laying out the one true path to software development. Whether it is a rails web app or a functional high frequency trading app, the author's point stands: don't let dogma dictate your testing strategy at the expense of harder to read, nastier to maintain code.

noir_lord 12y ago

MVC (like all good tools) has it's place. Shoehorning everything into MVC because it's the "one true way" is where the problems arise. My current system uses Controllers, Views, Services and Repositories with ORM objects as the "entities" (it's based on Laravel/Eloquent) and I've found that to be an acceptable trade off for the domain I'm modeling, MVC would have been painful when you have a lot of business logic.