The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:
|Screenshot of the alternative manifesto from http://programming-motherfucker.com/|
Before I start, I'll confess when I started my first programming job I agree 100% with the sentiment of this site - I thought the people managing me had crazy processes which did nothing but slow me down. Over time and as I progressed through the ranks, I guess my mentality has changed - that or I've been broken by managers ;-)
Firstly put your cards on the table and explain why a certain process is in place. If you are transparent and can explain why you have a process - truthfully - then you will gain respect. If you use a tool like JIRA or Rally to manage workload, explaining that its really to help you manage people's workload and help plan releases and how their use of these tools allow you to do that will at least help them understand. The key here is to ensure that firstly the admin they are required to do is as little and efficient as possible, and secondly to get their input into the process and how they think it could change to make their work easier. At the end of the day a business and jobs survives because it makes money, if someone cannot accept that then you shouldn't employ them anyway.
The second thing which really really helps, is to be good technically in the first place. If you are not only a manager, but a good programmer (mother******) then they wont feel like you are bullshitting them. I talk about this in my post can someone from a non-technical background manage a team of programmers?
You have to accept that you can't force people to do something, if you want them to do it well. Unit tests are a great example; you can force people to do them but they'll end up writing rubbish tests. If the programmers are engaged in why the team wants unit tests, then they'll write good tests.
The last thing you should do, is look at the table above and work out where you currently sit - are you closer to the "They Claim to value" column or the "They Really Value" column. If you are to the right, you should look at what you can do to move to the left. Have you gone too far in trying to manage the team that you have actually moved away from the basic principles?
It's an interesting topic - how do you deal with programmers who have this attitude? If you are a programmer what do you think managers can do to be more effective?