Hacker News Reader

Comment by zeemonkee2 | Hacker News Reader

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.

View on HN

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.

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.

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?

I said it makes no difference.

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.

All other things being equal, a "homegrown" project by coders who know what they're doing is going to be better than a framework project by coders who don't. Yes, I understand your reason, and given coders of equal ability it may be true; but I've seen Django projects written so badly the framework made very little difference to maintenance overhead (and as Django becomes more popular and mainstream we're going to see more examples of this).

Even a team of good coders often produces a worse homegrown solution due to the time pressures of their project. This in my opinion makes the chances of creating a better homegrown solution low. And you lose all the reuse abilities you get from a framework.

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.)

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.

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 :)

Reply on news.ycombinator.com