7 ms·

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 :)
  - jshen 14y ago
    I'm not sure you addressed the issue at hand. Others are arguing that using a framework will make your codebase worse in the long wrong. I'm asserting that all of the homegrown codebases I've worked with are worse than the ones using a framework, after a few years.
    - zeemonkee2 14y ago
      I'm not arguing against using a framework, if it fits your project requirements, and we can argue the day long about micro-vs-full-stack. There are good arguments for both, they suit different people and projects. My own observation is that bad codebases are the result of bad development practices regardless of framework. In my last job the code quality was so poor (and the management processes so broken) that whether they'd used Django, Flask or roll-your-own would not have made a whit of difference.
      - jshen 14y ago
        The original discussion was about a potential difference in the long term quality of a code base if they choose a framework over a homegrown solution. You aren't saying anything about that potential difference. Correct?
        zeemonkee2 14y ago
        I said it makes no difference.
        jshen 14y ago
        My experience says there is a difference. Allow me to offer one possible reason. A good framework gives a project a good structure to start with. Most homegrown solutions have to recreate much of the structure of the framework, and they often do a worse job than the highly developed frameworks that have the experience of many open source developers behind them.
        14y ago
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.

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 :)
- jshen 14y ago
  I'm not sure you addressed the issue at hand. Others are arguing that using a framework will make your codebase worse in the long wrong. I'm asserting that all of the homegrown codebases I've worked with are worse than the ones using a framework, after a few years.
  - zeemonkee2 14y ago
    I'm not arguing against using a framework, if it fits your project requirements, and we can argue the day long about micro-vs-full-stack. There are good arguments for both, they suit different people and projects. My own observation is that bad codebases are the result of bad development practices regardless of framework. In my last job the code quality was so poor (and the management processes so broken) that whether they'd used Django, Flask or roll-your-own would not have made a whit of difference.
    - jshen 14y ago
      The original discussion was about a potential difference in the long term quality of a code base if they choose a framework over a homegrown solution. You aren't saying anything about that potential difference. Correct?
      - zeemonkee2 14y ago
        I said it makes no difference.
        jshen 14y ago
        My experience says there is a difference. Allow me to offer one possible reason. A good framework gives a project a good structure to start with. Most homegrown solutions have to recreate much of the structure of the framework, and they often do a worse job than the highly developed frameworks that have the experience of many open source developers behind them.
        14y ago

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.