4 ms·

It's difficult to refute this line of thinking, except in practice. In practice, I think large frameworks are eventually pretty terrible. It's too easy to comp

It's difficult to refute this line of thinking, except in practice. In practice, I think large frameworks are eventually pretty terrible. It's too easy to compromise your business needs in small ways because the framework offers you something close-enough. Whether those compromises come in the form of over-coupling (which they always do with these frameworks), or in other ways like compromised URL design, query performance, or authorization plumbing. Great at first, but in my experience a project run long enough in one of these ecosystems tends to outgrow it. Being faced from the beginning with more of a blank sheet of paper and open ecosystem of solutions to choose from (or build) tends to make you more aware of the trade-offs, and how well the solution you're implementing fits your business needs. Costs more up front, but you're less likely to grow a hate-tumor during years 3-6.

jshen 14y ago
I've been writing web apps for a long time and for many different companies of different sizes. I've never, ever, seen a homegrown setup that was in better shape than the average rails app after a few years. Maybe your experience is different.
- anthonyb 14y ago
  Amen. I've seen quite a few projects that start out by rerolling the ORM, routing and templating, then grind to a halt under the weight of all the bugs before getting any significant features out the door.
  - zeemonkee2 14y ago
    In Python, you wouldn't reroll your own ORM, routing and templating - you'd use SQLAlchemy, Werkzeug, Jinja2/Mako/whatever.
    - jshen 14y ago
      Ad I've still never seen a homegrown solution that ties together libraries which was better off after a few years. Your experiences may differ.
      - nupark2 14y ago
        Mine do differ. Anecdotal evidence, after all.
      - zeemonkee2 14y ago
        Most codebases I've seen that are badly maintained or managed over the years are horrible messes - whether Django, Rails or anything else. The last codebase I worked on - written in Django - was appallingly bad. That's no fault in any way of Django, but no framework is going to save you from poor coders, last-minute rushed requirements, chronic technical debt, or lack of investment in refactoring.
        its_so_on 14y ago
        Could you summarize your suggested best practices (Specifically what you suggest is a good way to avoid at least some of the problems you list in your last sentence.)
        zeemonkee2 14y ago
        Really, it's more of a management problem than a coding problem. Short-term thinking, bad hiring/outsourcing practices, and poor client expectations management, among others. A framework or language isn't magic pixie dust that will make these problems go away. At this point I'd prefer to work on a well-managed, professionally coded project written in PHP than one written using <insert-python-framework-du-jour-here> run by idiot managers.
        Fledeskum 14y ago
        One of the factors I considered when I switched jobs earlier this year was that the new place has a policy of devoting 2 months a year to refactoring :)
    - anthonyb 14y ago
      I wouldn't, and I'm sure you wouldn't... but there are people who do. Case in point: OpenERP. Serious business software doing serious business things, so of course they can't use any of those other toy ORMs, they have to spend 5000 lines of code writing their own: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... Hey, it might not be so great, but at least they have tests for all of that code: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/tests/test_orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... Er... I know of other projects in a similar state, but they're smaller teams or solo coders, so I don't know that they're quite as fair game for finger pointing...
    - acdha 14y ago
      Which has an interesting balance: you're then using things developed in isolation, which can give you better parts but it definitely means you have to provide interconnect conventions and that new developers have to get used to your particular combination of parts. If you think you can do this better than the Django community, this can work out well but I'd say more often than not when I've heard about it people weren't actually able to spend enough time on this as they'd hoped and keep falling further and further behind Django and other frameworks.
      - zeemonkee2 14y ago
        Sure, if you did it completely on your own. More likely you use Flask or Pyramid which provide the plugins/entry points/templates to make wiring these components together quite easy.
- philwelch 14y ago
  Out of curiosity, what kind of shape is the average Rails app in after a few years?
tluyben2 14y ago
I have been creating software for 20+ years and I have personally never seen a case where 'in the end' it wouldn't have been better to use a framework. And mostly actually a framework which is as opinionated and feature rich as possible. These frameworks don't grow randomly; they are based on actual needs. When they are young they answer mostly to acute needs of the developer, when they grow they automatically grow into stuff 'most companies' need. And that's 'your company' as well; you can think you are different, but that's not really true. If you try to be different, you mostly do a lot of work which you shouldn't have. Yes, there is Google. Yes there is Facebook. But you are not those. And you won't become those. Also most companies are not IT companies; non-IT companies benefit even more from frameworks and rigidity; in most cases it's better to remake or form your business process to the framework/software than the other way around. Other people did that heavy lifting already; why should you try to do that again? I'm not sure where you work, but this is my experience from using 'wysiwyg' clipper & dbase software in the 80s to Delphi frameworks in the 90s to web frameworks. People think they are very different from the start and then (usually after a management change) they notice the same stuff happens everywhere.
- nahname 14y ago
  Are you talking about frameworks or software products? There is a very good argument around building custom software versus buying a product that matches your argument. In that case, I strongly agree. You should find products that either match your business process or change your process to match the products. With regards to frameworks. I find it hard to believe that none of them would work out in the long run. I wonder if you are under-estimating the cost involved from the developers to replace or create these frameworks from scratch. This also seems like a selection problem more than an inability of frameworks to meet any development need. I mean they do exist for a reason. That said, most software products are pretty horrible. Many frameworks are equally bad. Does this mean you should custom build everything? Of course not, you company is not going to be able to afford the time it takes you to write your own ORM, your own web framework, your own logging library, etc... It is your job to make compromises that will allow your company to achieve its goals.

jshen 14y ago

I've been writing web apps for a long time and for many different companies of different sizes. I've never, ever, seen a homegrown setup that was in better shape than the average rails app after a few years. Maybe your experience is different.

anthonyb 14y ago
Amen. I've seen quite a few projects that start out by rerolling the ORM, routing and templating, then grind to a halt under the weight of all the bugs before getting any significant features out the door.
- zeemonkee2 14y ago
  In Python, you wouldn't reroll your own ORM, routing and templating - you'd use SQLAlchemy, Werkzeug, Jinja2/Mako/whatever.
  - jshen 14y ago
    Ad I've still never seen a homegrown solution that ties together libraries which was better off after a few years. Your experiences may differ.
    - nupark2 14y ago
      Mine do differ. Anecdotal evidence, after all.
    - zeemonkee2 14y ago
      Most codebases I've seen that are badly maintained or managed over the years are horrible messes - whether Django, Rails or anything else. The last codebase I worked on - written in Django - was appallingly bad. That's no fault in any way of Django, but no framework is going to save you from poor coders, last-minute rushed requirements, chronic technical debt, or lack of investment in refactoring.
      - its_so_on 14y ago
        Could you summarize your suggested best practices (Specifically what you suggest is a good way to avoid at least some of the problems you list in your last sentence.)
        zeemonkee2 14y ago
        Really, it's more of a management problem than a coding problem. Short-term thinking, bad hiring/outsourcing practices, and poor client expectations management, among others. A framework or language isn't magic pixie dust that will make these problems go away. At this point I'd prefer to work on a well-managed, professionally coded project written in PHP than one written using <insert-python-framework-du-jour-here> run by idiot managers.
        Fledeskum 14y ago
        One of the factors I considered when I switched jobs earlier this year was that the new place has a policy of devoting 2 months a year to refactoring :)
  - anthonyb 14y ago
    I wouldn't, and I'm sure you wouldn't... but there are people who do. Case in point: OpenERP. Serious business software doing serious business things, so of course they can't use any of those other toy ORMs, they have to spend 5000 lines of code writing their own: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... Hey, it might not be so great, but at least they have tests for all of that code: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/tests/test_orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... Er... I know of other projects in a similar state, but they're smaller teams or solo coders, so I don't know that they're quite as fair game for finger pointing...
  - acdha 14y ago
    Which has an interesting balance: you're then using things developed in isolation, which can give you better parts but it definitely means you have to provide interconnect conventions and that new developers have to get used to your particular combination of parts. If you think you can do this better than the Django community, this can work out well but I'd say more often than not when I've heard about it people weren't actually able to spend enough time on this as they'd hoped and keep falling further and further behind Django and other frameworks.
    - zeemonkee2 14y ago
      Sure, if you did it completely on your own. More likely you use Flask or Pyramid which provide the plugins/entry points/templates to make wiring these components together quite easy.
philwelch 14y ago
Out of curiosity, what kind of shape is the average Rails app in after a few years?

tluyben2 14y ago

I have been creating software for 20+ years and I have personally never seen a case where 'in the end' it wouldn't have been better to use a framework. And mostly actually a framework which is as opinionated and feature rich as possible. These frameworks don't grow randomly; they are based on actual needs. When they are young they answer mostly to acute needs of the developer, when they grow they automatically grow into stuff 'most companies' need. And that's 'your company' as well; you can think you are different, but that's not really true. If you try to be different, you mostly do a lot of work which you shouldn't have. Yes, there is Google. Yes there is Facebook. But you are not those. And you won't become those. Also most companies are not IT companies; non-IT companies benefit even more from frameworks and rigidity; in most cases it's better to remake or form your business process to the framework/software than the other way around. Other people did that heavy lifting already; why should you try to do that again? I'm not sure where you work, but this is my experience from using 'wysiwyg' clipper & dbase software in the 80s to Delphi frameworks in the 90s to web frameworks. People think they are very different from the start and then (usually after a management change) they notice the same stuff happens everywhere.

nahname 14y ago
Are you talking about frameworks or software products? There is a very good argument around building custom software versus buying a product that matches your argument. In that case, I strongly agree. You should find products that either match your business process or change your process to match the products. With regards to frameworks. I find it hard to believe that none of them would work out in the long run. I wonder if you are under-estimating the cost involved from the developers to replace or create these frameworks from scratch. This also seems like a selection problem more than an inability of frameworks to meet any development need. I mean they do exist for a reason. That said, most software products are pretty horrible. Many frameworks are equally bad. Does this mean you should custom build everything? Of course not, you company is not going to be able to afford the time it takes you to write your own ORM, your own web framework, your own logging library, etc... It is your job to make compromises that will allow your company to achieve its goals.