Though my daily work involves plenty of DI, and I see the need for it, I see some unfortunate side-effects, in the behaviours it 'causes'. - the 'autopilot GPS

Though my daily work involves plenty of DI, and I see the need for it, I see some unfortunate side-effects, in the behaviours it 'causes'. - the 'autopilot GPS' problem: Colleagues who basically have no idea how things fit together, because DI connects the dots for them. So they end up with either a vague or no mental model of that happens below the surface. - the same, but related to scope and costs: Costs: Because they don't touch what is 'built behind the scenes', they get no sense of how costly it is ('every time you do use that thing, it instantiates and throws away a million things'). Scope: Often business logic dictates that the construction hierarchy consists of finely tuned parts: You don't just need an instance of 'Foo', you need a Foo instance that originates from a specific / certain request. And if you then use two Bar's together, where Bar 1 is tied to Foo 1 but Bar 2 is tied to Foo 2, you will get strange spurious errors (think, for example, ORMS and database transactions - the two Foos or Bars may relate to different connections, transactions or cursors.) One antipattern I have seen (which may actually be an argument FOR DI..), is the 'query everything' service, which incorporates 117 other sub-services. And some of the junior developers just love that service, because "then I can query everything, from a single place!" (yes.. but you just connected to 4 databases with 7 connections, and you are only trying to select a single row from one of them. And again, code with the everything-service becomes quite untestable). The best part of the article is its advice for triggering the broken dependencies at compile-time, I really hate when I have to go through complicated flow #127 to learn that a dependency is broken.