"However, there's a stranger breed that I've encountered: the engineer who has somehow forgotten how to look at things from a traditional software engineer's perspective. This odd creature has little trouble explaining how his work supports the company's broader goals. Yet he has difficultly communicating with the more common engineers--those who mainly see technology"

Perhaps its not that some of these strange-engineers have forgotten how to look at things in a traditional sense, but rather, by some fluke, slipped through the educational cracks and were never even taught; and were even unaware of this themselves until they found themselves out of school and immersed in a world that they have no clue how to function in. These strange-engineers however, by personal-interest, and by lack of any other available informational resources, were skilled in the jargon used by the company's bigwigs.

Desperate to keep their life-time job, some of these strange engineers who love what they do, attempt to throw themsleves into the board meetings between the big wigs and the engineers and simultaneously try to explain the information he holds to both parties, hoping that just by the sheer number of members in attendance, that maybe, hopefully at least one person on that board might have been educated in both engineering and in corporate training so that they might properly clarify the important information held inside the mind of that crazy-engineer. This method, although effective, is extremely inefficient and doomed to failure since the board has more important issues to discuss at their time-dependent meetings than the obscure and easily misinterpreted ramblings of the new and odd junior engineer.

Even if this odd-engineer does finds by chance that certain board member who fully understands the dealings of both parties, they are already of such high need and of high-responsibility to the rest of the company that it would be a continually unreliable and hard to get contact. This unfortunate turn of events would not render the odd-engineer a useful permanent asset to the company, regardless of any contributable abilities he might possess.

However,if that unique board member had alloted just but enough of her busy and important schedule to to have directed that odd-engineer to someone who could better help, then perhaps his lifetime engineering possibilities could be saved. Probably the best situation would be if they could find a fellow software engineer, one the odd-engineer was familiar with, trusted (and had a very confused (but honest and deep) fondness for) and who had an amazing and almost unbelievable talent with people skills. Then maybe, just maybe that odd engineer would have found someone whom he could spend a lot of time working with, who could decipher the bizarre and zany information that burst forth from that odd-engineers mind. Then that odd-engineer might be able to contribute his many ideas to that company he worked so hard for his whole life to be a part of, and more importantly maybe make a very special friend among his co-workers, if they were in fact, willing to be his special friend, of course. :)

so thats what i say.

My general experience with XP:

1. Unit testing is very good when it's feasable (there are some situations involving human interaction where throwing a QA person at it on a regular basis is substantially easier than trying to rig something to fake the user input).

2. Pairs programming works under very specific circumstances (which don't seem to arise with small programming teams in the games industry). The one place I have found pairs programming to be very useful is when you're dealing with a very junior programmer who needs to be brought up to speed quickly. In college learned a ton of C/C++ and shell programming by sharing a terminal with a grad student.

3. A large number of XP advocates that I've encountered or heard about (a number probably not representitive of the total number of XP advocates) seem to be enamoured with it entirely due to the name. They seem to want to do one thing (usually pairs programming) just so that they can say they're using XP. Maybe they're trying to pick up women with it ("Hey baby, I'm into Extreme Programming.") These people should be lined up and beaten.

4. There are a lot of good ideas that are described in XP. The most important thing to do is to look at those ideas as individual ideas and see which ones work well for your dev team. It's like Design Patterns: People who view the book as a ToDo list have completely missed the point and should be beaten.

Kasia,
Are your fellow workers invading your blog and dropping hints and trying to influence you or something?

I am merely providing personal data. kasia may interpret this information in any way she sees fit. she is a very smart girl and her judgement should be trusted.