5 ms·

This sort of attitude worries me, you don't need to use a framework to get this, you just need developers who have some knowledge of design/architecture, or who

This sort of attitude worries me, you don't need to use a framework to get this, you just need developers who have some knowledge of design/architecture, or who are the sort of people who will do research to find out. I honestly think the framework enforcing architecture idea is more of an anti-pattern, even if you do use a framework you need to keep in mind that it wasn't built directly to fit your needs and that you may want/need to move in 6 months or a year.

davedx 12y ago
Adopting a well designed, thought through and battle tested architecture is definitely not an anti-pattern. Re-inventing your own is worse. I often find myself referring to e.g. Ruby on Rails for architecture decisions, as opposed to trying to roll my own. Architecture is hard.
- mattgreenrocks 12y ago
  This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it." If it's hard, you learn it so it isn't so scary. You build one to throw it away, as Brooks recommends in The Mythical Man Month. I want nothing to do with an industry so obsessed with maintaining its own passivity and ignorance of practices. The truth is: a good architecture is highly liberating. It segregates responsibilities, enabling developers to spin up quickly. It makes it easy to spread work among devs of varying skill and experience. It makes maintenance a pleasure or a complete grind. You have the ability to make working in your code base an enjoyable process of exploring a particular problem domain. But to get there, you need to think deeply about how data flows from inputs to outputs. It's fine to skip these steps via a framework, but you're also trading off how good future maintenance. There is nothing special about the web that requires frameworks. They're a modern preoccupation, just like OOP was, or components were. In the end, good engineering is what's required, not blind faith in commoditized tooling. Learn the fundamentals of software design.
  - marrs 12y ago
    What's more, if you developed your framework in-house, devs feel more empowered to improve it and tailor it to their needs.
    - fadzlan 12y ago
      I think that depends on how good is the framework is architecturally sound in the beginning AND where you work. I had a case where we had our own internal framework. Its okay. But the team turnover is quite bad to an already tight deadline that I had to re-explain everything every time a new dev comes in. That framework has no routing(its basically for multipage app) and guess what, if someone decide that they need routing, that guy is going to create his own, and there might be two of these guys, so then we have two ways of doing routing then. And given the fact that this team has high turn over and tight deadline, I don't think you can say that it'd make a cohesive team, and the communication channel that everyone has is already overloaded (loads of meetings). Sure, that may be a bad project to begin with, but that would be a different story. In this case, at least for me, using a standard framework would be no brainer.
  - mikegioia 12y ago
    I think you've just done a really good job explaining the differences between good developers and great developers. Good developers display that anti-intellectualism, but great developers spend the time to learn what they don't know and design a system that fits their problem.
    - davedx 12y ago
      I could not disagree more. Great developers know their limits and when it's appropriate to choose third party tools and when to roll their own. Chances are, if you think it's time to roll your own, you just think you're better than you are. http://en.wikipedia.org/wiki/Not_invented_here http://en.wikipedia.org/wiki/Not_invented_here
      - mikegioia 12y ago
- colin_jack 12y ago
  I agree with the other replies but when you talk about learning from Rails, I agree. I also don't think using Rails is a bad idea. However I find the idea that if you don't use a framework to literally force you down a path you're on your own, that chaos will be dogging the project, that you end up with massive re-invention, to be incorrect. Rails is also a bit of a special case I think, it was a massive ecosystem that dominated the community it was in. That isn't true of any JS client-side framework right now so choosing one isn't necessarily a sensible investment when you look 3+ so years out.

davedx 12y ago

Adopting a well designed, thought through and battle tested architecture is definitely not an anti-pattern. Re-inventing your own is worse. I often find myself referring to e.g. Ruby on Rails for architecture decisions, as opposed to trying to roll my own. Architecture is hard.

mattgreenrocks 12y ago
This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it." If it's hard, you learn it so it isn't so scary. You build one to throw it away, as Brooks recommends in The Mythical Man Month. I want nothing to do with an industry so obsessed with maintaining its own passivity and ignorance of practices. The truth is: a good architecture is highly liberating. It segregates responsibilities, enabling developers to spin up quickly. It makes it easy to spread work among devs of varying skill and experience. It makes maintenance a pleasure or a complete grind. You have the ability to make working in your code base an enjoyable process of exploring a particular problem domain. But to get there, you need to think deeply about how data flows from inputs to outputs. It's fine to skip these steps via a framework, but you're also trading off how good future maintenance. There is nothing special about the web that requires frameworks. They're a modern preoccupation, just like OOP was, or components were. In the end, good engineering is what's required, not blind faith in commoditized tooling. Learn the fundamentals of software design.
- marrs 12y ago
  What's more, if you developed your framework in-house, devs feel more empowered to improve it and tailor it to their needs.
  - fadzlan 12y ago
    I think that depends on how good is the framework is architecturally sound in the beginning AND where you work. I had a case where we had our own internal framework. Its okay. But the team turnover is quite bad to an already tight deadline that I had to re-explain everything every time a new dev comes in. That framework has no routing(its basically for multipage app) and guess what, if someone decide that they need routing, that guy is going to create his own, and there might be two of these guys, so then we have two ways of doing routing then. And given the fact that this team has high turn over and tight deadline, I don't think you can say that it'd make a cohesive team, and the communication channel that everyone has is already overloaded (loads of meetings). Sure, that may be a bad project to begin with, but that would be a different story. In this case, at least for me, using a standard framework would be no brainer.
- mikegioia 12y ago
  I think you've just done a really good job explaining the differences between good developers and great developers. Good developers display that anti-intellectualism, but great developers spend the time to learn what they don't know and design a system that fits their problem.
  - davedx 12y ago
    I could not disagree more. Great developers know their limits and when it's appropriate to choose third party tools and when to roll their own. Chances are, if you think it's time to roll your own, you just think you're better than you are. http://en.wikipedia.org/wiki/Not_invented_here http://en.wikipedia.org/wiki/Not_invented_here
    - mikegioia 12y ago
colin_jack 12y ago
I agree with the other replies but when you talk about learning from Rails, I agree. I also don't think using Rails is a bad idea. However I find the idea that if you don't use a framework to literally force you down a path you're on your own, that chaos will be dogging the project, that you end up with massive re-invention, to be incorrect. Rails is also a bit of a special case I think, it was a massive ecosystem that dominated the community it was in. That isn't true of any JS client-side framework right now so choosing one isn't necessarily a sensible investment when you look 3+ so years out.