4 ms·

There is also a trickier and more interesting case 3: Experienced guy in his 50's, seen it all before. Remembers the era of object databases, knows why SQL was

There is also a trickier and more interesting case 3: Experienced guy in his 50's, seen it all before. Remembers the era of object databases, knows why SQL was invented, and shuts down his hipster colleague's plans to use Mongodb. Remembers CORBA, SOA and J2EE and is skeptical about microservices. Understands why logging/metrics/dependency injection is necessary and pushes RoR guys to use more verbose syntax to support it. Younger folks dislike him because of this. There is conflict. Management has a real problem, since they both need experience but the senior guy can't build everything on his own.

1stop 12y ago
dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say)... (Same with metrics, they can easily be injected into the entire object tree). Logging sure, you need to write some of that. There are also arguments for NoSQL dbs as well, some times old knowledge is exactly that. This doesn't seem to be a compelling example... But alas, I think I've taken this off topic.
- BugBrother 12y ago
  yummyfajitas' point about noSQL DBs was -- the old guy saw DBs before SQL was created and understand the trade offs.
- pionar 12y ago
  > dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say) Disclaimer: not a RoR guy. Dependency injection isn't about unit tests. Dependency injection is about weak dependencies, easier refactoring, and preventing bad design decisions from being a disaster 5 years down the line. Dependency injection is a good idea no matter what the language/framework is. That's the point of the parent comment. A dev in his 50s would point these things out.
  - barrkel 12y ago
    Dependency injection in practice is almost always implemented for tests. In terms of architecture, it's usually a case of YAGNI. Every dependency injected is a configuration point that is almost never altered, except for mocks in testing. When this style infects a whole codebase, it makes it far harder to read and navigate, because code flow is dependent on runtime data flow. Heavy use of indirections that only ever go to the one place is a bad code smell, and it's a stench over the entire field of enterprise Java. Code that is easy to read is easy to refactor. Except for natural architectural chokepoints that are typically intrinsic to the problem being solved, you're fooling yourself if you don't think architecture changes are needed for most refactoring - dependency injection isn't buying you what you think you're buying. Every injection point you create is a prediction about the future, about the possibilities of change, but there's one gotcha: the future is hard to predict, so most of your decisions are wrong. You're better off being agile, following YAGNI, doing the simplest thing that will work, and altering it when requirements change.
    - yummyfajitas 12y ago
      I've done DI many times for things other than tests - swapping out different algorithms is the most common case (BetaBanditCalculator -> TimeVaryingBayesianBanditCalculator -> HierarchicalPersonalCharacteristicCalculator, etc). It also makes testing easy, which is great, but that's far from the only use case. DI tends to work great for the integration point between systems - e.g., connecting the REST or Thrift interface to the calculation backend and datastore. The fact that a concept is hard to use in Enterprise Java is a poor argument against anything other than Enterprise Java.
    - alexdowad 12y ago
      One extra point: what @barrkel is saying here works much better in a language which is fairly concise. In more verbose languages, any kind of change becomes more difficult (there is simply more code to change and more opportunities to make mistakes), so it is understandable that people want to build in "hooks" for extension.
    - pacala 12y ago

1stop 12y ago

dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say)... (Same with metrics, they can easily be injected into the entire object tree). Logging sure, you need to write some of that. There are also arguments for NoSQL dbs as well, some times old knowledge is exactly that. This doesn't seem to be a compelling example... But alas, I think I've taken this off topic.

BugBrother 12y ago
yummyfajitas' point about noSQL DBs was -- the old guy saw DBs before SQL was created and understand the trade offs.
pionar 12y ago
> dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say) Disclaimer: not a RoR guy. Dependency injection isn't about unit tests. Dependency injection is about weak dependencies, easier refactoring, and preventing bad design decisions from being a disaster 5 years down the line. Dependency injection is a good idea no matter what the language/framework is. That's the point of the parent comment. A dev in his 50s would point these things out.
- barrkel 12y ago
  Dependency injection in practice is almost always implemented for tests. In terms of architecture, it's usually a case of YAGNI. Every dependency injected is a configuration point that is almost never altered, except for mocks in testing. When this style infects a whole codebase, it makes it far harder to read and navigate, because code flow is dependent on runtime data flow. Heavy use of indirections that only ever go to the one place is a bad code smell, and it's a stench over the entire field of enterprise Java. Code that is easy to read is easy to refactor. Except for natural architectural chokepoints that are typically intrinsic to the problem being solved, you're fooling yourself if you don't think architecture changes are needed for most refactoring - dependency injection isn't buying you what you think you're buying. Every injection point you create is a prediction about the future, about the possibilities of change, but there's one gotcha: the future is hard to predict, so most of your decisions are wrong. You're better off being agile, following YAGNI, doing the simplest thing that will work, and altering it when requirements change.
  - yummyfajitas 12y ago
    I've done DI many times for things other than tests - swapping out different algorithms is the most common case (BetaBanditCalculator -> TimeVaryingBayesianBanditCalculator -> HierarchicalPersonalCharacteristicCalculator, etc). It also makes testing easy, which is great, but that's far from the only use case. DI tends to work great for the integration point between systems - e.g., connecting the REST or Thrift interface to the calculation backend and datastore. The fact that a concept is hard to use in Enterprise Java is a poor argument against anything other than Enterprise Java.
  - alexdowad 12y ago
    One extra point: what @barrkel is saying here works much better in a language which is fairly concise. In more verbose languages, any kind of change becomes more difficult (there is simply more code to change and more opportunities to make mistakes), so it is understandable that people want to build in "hooks" for extension.
  - pacala 12y ago