What's really powerful about these terms is how much they say at once. Immediately in my head I conjure up visions of how something is actually implemented (static method with private constructor, a factory, etc). That's nice. So much I don't have to think about. It sort of lets me reject possibilities or to assign probabilities in my brain and this makes the system rather easier to grok.

At work we're using a form of dependency injection (IoC if you prefer). Our form has some rules that make sense in the context of us. One of those rules is that when you are injecting a dependency into the system, you cannot ask for another dependency. If you need to do that, there is a specific and defined way of being initialized. To enforce this rule there is some little bit of code that will tell you, at runtime, if you're trying to violate it. So when someone says something like, "So I'll init() the component and access the JMX stuff when it gets started()", what I hear is something pretty specific. init is the de facto IoC injection point for us, and I know if I look at it it will have just a few very simple lines of code, and start() has it's own set of semantics that are not really part of this discussion. I tend to call this "fat pipe" communication to suggest its high bandwidth, low latency nature. I believe it's incredibly valuable and is one of the larger contributers to building good systems.

The other day I was splashing about in a part of the system that hasn't fallen under the dependency injection stuff yet. I happened to want to do something that could be accomplished in, of course, a bunch of different ways but we're using dep...ok, I'm going to say IoC now because it's easier to type...we're using IoC so I decided to go that way (It's probably impossible for me to overstate how important I think consistency in a system is). I had written, essentially, the rule about not getting dependencies during initialization but I wanted to make sure I had the details right. So I jumped over to a the rule enforcement code bit to take a quick look. Imagine my surprise (he said with great political savvy) to see some new chunk of code designed entirely to get around this rule.

To willfully subvert something in the system without understanding fully (fully!) why the something happens to be there is rather less than optimal (he said, again applying his great political savvy). Undoubtedly schedule pressure had something to do with it, but I'm still at a loss as to why even the briefest of conversations didn't occur.

Larger systems can have a great deal of nuance. The younger the system, the less disciplined and the smarter the developers [perceive themselves to be], the more nuance there is. When someone moves into an unfamiliar bit of the system coming to understand the nuance, the rules, can take a lot, and I do mean a lot, of time. Taking the time to learn these things can really gronk up your estimates. In a system with lots and lots of rules, idioms and ways of doing things, if you happen to move all over the place there is a finite number of times one is willing to go to the daily meeting and say you're going to take longer than you expected (there is also a finite number of times those who judge will be happy to hear you say it).