Cedric is talking about falling in love with one's own code.  Wow, this is tricky.  Cedric's right, but at the same time I feel the need to defend the other side.

First of all, I suppose that I'm one of the least loved developers on my team, because I'm pretty hard on testers.  My (admittedly pitiful) excuse is that it's a combination of high standards and high stress.  I get really irritable when testers don't give a good reproduction sequence, when they don't tell you what server they were testing against, or when they don't give you the full error text (when you're testing a SOAP system, it's not OK to say that a web service returned HTTP Error 500).  That's my problem, I lack patience and get tired of asking people over and over to give me good information so I don't burn a half hour trying to find out what the bug report should have told me.  But it's not an excuse for being rude. 

But you also get the reverse effect: testers who get angry when a programmer tells them that their bug isn't a "Priority 1 Critical", or that testers don't get to dictate requirements.  This latter is a huge problem at my work; our testers file a lot of usability bugs, and programmers tend to treat this as any other bug.  This is a bad idea; UI design should be thought out in advance, and QA doesn't get to dictate changes, not unless they have a dual role as usability experts. 

There's a third problem here.  There's a feeling of ownership that comes with taking pride in your work, and I don't want to work with people who don't take pride.  I think that because of that, there's got to be a tension between testers and developers.  But there's got to be a limit to it; hopefully everybody's working towards a common goal, and hopefully, everybody remembers that when the bug reports start rolling in.

I wonder if anyone is willing to provide a VERY simple tutorial/description of AOP, with maybe a few simple code examples.[PSquad's Corner]

On a practical level, the problem I see AOP trying to solve is that good production code contains a lot of code that's necessary, but isn't part of the basic goal of the code. For example, logging and auditing, transactional attributes, or configuration. Your banking software might have the requirement that the "Transfer Money" use case be fully auditable, that it must be transactional (no withdrawing money from one account unless it's confirmed deposited in another), but those are side requirements to the goal that you want to move money from one account to another. The key words are "Separation of Concerns". So far, I like Preparing for the AOP Tide best. I Want My AOP! delves into AspectJ, part 1 is an OK 30k ft view.