Extremes in anything (IMHO) are typically not good. Extreme temperatures, religeons, attitudes -- you name it, likely there is a downside. In programming, it's no different. Now, while not a big fan of Extreme Programming, there's a couple of extremes from it that bother me. One is that you shouldn't include documentation. The other, which I suspect  was someone's personal preference, was not to use the “Region” directives in C# (or I guess VB.Net either). Here's a little history...

This guy was a former Java programmer working for a large chip manufacturer. He was supposed to be a XP guru, so he was transferred to the local site to help a team in it's transition to the XP methodology.

Strike 1 -- he knew the methodology well, but he was by no means an expert in the language of the group. Why was this a strike? I guess technological bias in that his preferences to his other language directed him to want to make the .Net environment the same as a java environment.

Strike 2 -- It was his way or the highway. The environment was such that one or two developers had 95% of the say on development decisions. Part of the reason for this is that wacky trend in which everyone is ranked from best to worst in terms of raises, options and promotion (for more info what I am talking about, read this article, which is the same process -- Saying Goodbye). No one would ever argue with the two for fear of getting a bad ranking for being considered a troublemaker.

Regardless, I digress, but I do think it's important to understand why sometimes these extremes come about in an environment. I was a contractor brought on to bring some quick wins for a project, and it was my first (and likely last) venture into the XP methodology. They needed code, and they needed it fast.

One problem I addressed was the lack of uniformity on the project. We had three developers, which meant three different styles of programming. Even with XP, that meant one of us was alone, and the other two would spend the pair time arguning over which style was a standard and best (even though standards existed -- they were just never used because of informal rules imposed by the 2 'chiefs'). I decided to create a template which would standardize (and speed up) our development. I organized the code within the controls into regions, and deployed them onto our machines with anticipation I easily saved our team15-20 minutes each time we created a new control.

Alas, it was scrapped instantly. Why? Well, it seems in my templates, I placed the code into logical “regions” -- e.g. Public Properties, Public Methods, Private Methods, etc. I was “informed” (even though I had been using regions for a couple of months now) that regions were not allowed, because all they did was hide bad code. WHAT???!! Well, I liked the contract, and knew the results if I stood up to them, so I bit my tongue and moved on. It has bothered me ever since, but I never took the time to formulate an argument as to why regions are actually a good idea.

Why bring this up today after a year has passed? Well, I was coding something, and the constructor was hidden by a region. I was thinking “Hmm, if we just left the constructors out of regions, it would be easy to read, because the regions would hide the internal implementations I don't care about, yet at a glance I can see how to instantiate the object” (hmm, I think they call that encapsulation) and use it. Now that right there justifies the use of regions alone.... I can actually think of a lot of reasons to use regions, and I do it religeously where my client has no opition about it.

Just a flashback from the past.... anyone got a counter opinion? Regardless, it just goes to show extreme anything typically isn't a good thing in my mind. You have to be flexible in your approach to life if you plan on growing...