3 ms·

It also reduces the learning curve when a new employee joins the team. If it is a widely used framework, they may have used it previously. If not, there will

by Johnie 11y ago

It also reduces the learning curve when a new employee joins the team. If it is a widely used framework, they may have used it previously. If not, there will be ample information and resources to learn it. As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization. When I was at Google, there was a widely used application framework. It enabled getting services up and running quickly and allowed quick integration into other services at Google. New team members can join and quickly be productive. Some teams decided to roll their own stack and many of them turned into a hairy ball of mess.

pilsetnieks 11y ago
> When I was at Google, there was a widely used application framework It was still organization-specific, probably embedded with a lot of the organizational know-how, and tailored for Google's use cases. Which is maybe not the case with the public generic "kitchen sink" frameworks out there.
- deleted 11y ago
  [deleted]
- onion2k 11y ago
  Which is maybe not the case with the public generic "kitchen sink" frameworks out there. In the case of Google's tailored, use case specific code, they release their frameworks publicly. Angular, Polymer, Guice, etc are all what you describe, and all freely available to businesses outside of Google. If your argument is that developers should look beyond the obvious "kitchen sink" frameworks and choose tools that match their requirements criteria as well as possible without adding in unnecessary features then I agree with you completely, but that argument is significantly different to "don't use a framework".
  - iainmerrick 11y ago
    Angular, Polymer, Guice, etc I don't necessarily disagree, but the fact they release so many different (and incompatible) frameworks should tell us something...!
    - onion2k 11y ago
      It tells us is that Google is huge and does lots of different things, and that there isn't such a thing as "one framework to rule them all". That doesn't mean frameworks are a bad idea.
      - iainmerrick 11y ago
        Yep, that's pretty much what I was going for. With maybe a slightly more negative spin -- they seem to experience NIH syndrome even with respect to internal tools, to the extent of developing multiple frameworks that do basically the same thing.
lmm 11y ago
> As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization. There's an important difference between a library and a framework. Code reuse is great, norms are great, but they need to be composable, and they need to follow the normal rules of the language. E.g. Spray is my favourite way of doing REST APIs and saves a huge amount of time, but it's a library rather than a framework. I write my own main() (which admittedly may well just be a one-liner that calls into Spray), and it doesn't dictate what other pieces I use - I can do dependency injection my own way or not at all, I can do my own ORM or none, I can use my own unit testing framework or none. I can refactor my Spray code in the ordinary ways of refactoring in Scala because it is just ordinary Scala, and if I want to understand what the library is doing I can click through to the definitions of the library methods which are again just ordinary Scala. For a large project we might all agree on a particular stack - Spray/Hibernate/Guice/JUnit, say - and we might even write some helpers for e.g. constructing a Guice context with Hibernate configured and pulling out the Spray service from it as a one-liner. But I'd still want those pieces to be libraries rather than frameworks as far as possible - I'd want inlining and changing that helper to be a supported use case, partly because it just forces good design (loose coupling, lack of globals etc.) and partly because making it possible for small subteams to experimentally swap out one small component for their piece is the only way one can ever improve on the stack.

by Johnie 11y ago

pilsetnieks 11y ago

> When I was at Google, there was a widely used application framework It was still organization-specific, probably embedded with a lot of the organizational know-how, and tailored for Google's use cases. Which is maybe not the case with the public generic "kitchen sink" frameworks out there.

deleted 11y ago
[deleted]
onion2k 11y ago
Which is maybe not the case with the public generic "kitchen sink" frameworks out there. In the case of Google's tailored, use case specific code, they release their frameworks publicly. Angular, Polymer, Guice, etc are all what you describe, and all freely available to businesses outside of Google. If your argument is that developers should look beyond the obvious "kitchen sink" frameworks and choose tools that match their requirements criteria as well as possible without adding in unnecessary features then I agree with you completely, but that argument is significantly different to "don't use a framework".
- iainmerrick 11y ago
  Angular, Polymer, Guice, etc I don't necessarily disagree, but the fact they release so many different (and incompatible) frameworks should tell us something...!
  - onion2k 11y ago
    It tells us is that Google is huge and does lots of different things, and that there isn't such a thing as "one framework to rule them all". That doesn't mean frameworks are a bad idea.
    - iainmerrick 11y ago
      Yep, that's pretty much what I was going for. With maybe a slightly more negative spin -- they seem to experience NIH syndrome even with respect to internal tools, to the extent of developing multiple frameworks that do basically the same thing.

lmm 11y ago

> As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization. There's an important difference between a library and a framework. Code reuse is great, norms are great, but they need to be composable, and they need to follow the normal rules of the language. E.g. Spray is my favourite way of doing REST APIs and saves a huge amount of time, but it's a library rather than a framework. I write my own main() (which admittedly may well just be a one-liner that calls into Spray), and it doesn't dictate what other pieces I use - I can do dependency injection my own way or not at all, I can do my own ORM or none, I can use my own unit testing framework or none. I can refactor my Spray code in the ordinary ways of refactoring in Scala because it is just ordinary Scala, and if I want to understand what the library is doing I can click through to the definitions of the library methods which are again just ordinary Scala. For a large project we might all agree on a particular stack - Spray/Hibernate/Guice/JUnit, say - and we might even write some helpers for e.g. constructing a Guice context with Hibernate configured and pulling out the Spray service from it as a one-liner. But I'd still want those pieces to be libraries rather than frameworks as far as possible - I'd want inlining and changing that helper to be a supported use case, partly because it just forces good design (loose coupling, lack of globals etc.) and partly because making it possible for small subteams to experimentally swap out one small component for their piece is the only way one can ever improve on the stack.