I came, I coded, I debugged.

The Good Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI , numerous DI frameworks have arisen ( Spring , Guice , Castle Windsor , etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application. I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same. 

Feature flags have always made me feel ambivalent. On one hand, I can relate to the need for having a mechanism to easily enable or disable particular features, while on the other hand, being a software engineer I pretty much loathe this concept, since feature flags make your code ugly more often than not. Especially if such a flag is left in place even after its corresponding feature has become fully operational, eliminating any practical need to be turned off on demand. Cliché ahead in 3,2,1: not everything in life is black and white, and sometimes, even in the face of feature flags, we can still, well, save face.