I think my mother told me this. Or maybe it was the principal.
The cost of communication is enormously high, especially in a development organization where one may be communicating using fairly nuanced terms. This tends to create vernaculars and colloquialisms unique to just about every crew I've been a part of and in turn fuels some seriously unusual statements. I don't know what I sound like when I'm saying things like, "Yah, I added a meta-fark onto the gleepmore thing in the pre-transform layer", but I do know my wife looks at me like I'm from Betelgeuse when I tell her about my day.
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).
I guess there is any point to this it's that if you want to be agile, if you want to go faster and deliver higher quality code, maybe striving for consistency instead of expediency is worthwhile. Maybe that should be a rule.
I'm currently engaged in my first "opportunity" (how's that for political savvy?) doing long-term maintenance on an application of substantial size. Sure, sure, I heard it a million times - "consistency is important for maintenance", but there's nothing like experiencing amazing inconsistency, and having to work with that, to really drive the point. For example, we currently do persistence using 4!!! completely different mechanisms - CMP EJB, Hibernate, POJO DAOs, and some home brewed 'SQLProcessor' API. The comment atop the main interface to the latter begins: "Main class for performing all SQL operations...". Yeah, right! Classic case of two many different groups contributing to the project, and not enough communication and/or shared vision.
On a past project, we had 2 differing opinions on how to do property file access. As a young "acting team lead", I didn't want to be a hard @$$, and not let a contractor use his preffered approach to what we had already been doing for the last year or so. Thus, we decided that having 2 conventions for property access was OK. Never Again! Not that it was a problem then (though I'm sure it's caused some confusion for maintainers of that app). But I've seen how truly annoying inconsistency is for the software maintainer. I'll always strive to push for consistency of approach here on out...
I think that "thin-pipe" is a better name than fat - it's not actually high-bandwidth. Consider, as an analogy, modem compression. If you want to send a big-but-commonly-ocurring sequence, the compression (ideally) sends it once (consider this the definition) and then refers to it by some appropriate shorthand that's quick to send but references the whole concept (okay, the metaphor is now officially overstretched). Thus a term like "gleeble" can mean "to create and initialize an object in an atomic operation", or something equally specialized. My favourite example is "grok", one syllable that conveys an entire specialized and expanded meaning of "understand", itself a 3 syllable word.