Posts
In the decades of the young life of software development, we've discovered many behaviors, processes, and techniques which have nothing to do with software yet continue to hold back progress. We ask time and time again why the mythical silver bullet is still searched for by those who have already agreed that it is a fools errand. Why are death-marches allowed to form when the futility is obvious to all but the oblivious? Why are proven techniques not mandated by management or agreed to by the workers who constantly complain about the current poor practices? This is true whether we're discussing XP or Agile or SCRUM.
We can use rational thought to decipher the mystery, attempting to achieve clarity. However much success is possible in finding rational explanations, there comes a time when we must recognize the difference between clarity and understanding. We can state things extremely clearly and succinctly and still fail to understand why people continue their unproductive habits or why change is viewed by those in charge with such disdain.
Submitted here for your edification, The 48 Laws of Power.
Why does that developer refuse to pair with someone? There are lots of reasons, i.e. Law #1 - Never Outshine the Master or law #30 - Make your Accomplishments Seem Effortless, are good places to start. Why is Continuous Integration scoffed at? See law #11 - Learn to Keep People Dependent on You
The words 'politics' or 'management' may seem like pejoratives but they serve as simple placeholders for the understanding of human behavior. At their worst, they can be weapons in a Machiavellian conflict while at their best they can be the protective shield against those who see your efforts as a challenge to their plans. Is every use of these laws an instance of plotting and scheming? No, never forget that human nature operates below the level of conscious thought; these behaviors are ancient artifacts used for thousands of years to survive in a violent and irrational world. Disagree with them all you'd like but ignoring them can easily cost you your job.
Monday, June 01, 2009
Subscribe to:
Post Comments (Atom)
Have you actually tried pair programming?
ReplyDeletethis is dumb
ReplyDeleteActually, I have used pair programming for a large transaction based legacy-replacement application and have been an advocate of the practice ever since, along with unit testing and continuous integration. If we know a technique works, the question becomes what keeps it from becoming more widespread which brings us to this post.
ReplyDeleteI've worked with people who seem to follow these rules you present, they usually end up as miserable CEO's or ostracized and then made redundant. The route to success and happiness is in cooperation, but it takes several years of working to realise this.
ReplyDeleteI detest pair programming. I'm a fan of shared workspace/smokebreaks though. Two people working on different components of the same task, in the same area working. You work for a bit, someone starts looking flustered, stands up, shouts "SMOKE BREAK" and you grab some coffee and go chill outside for a bit (whether you're smokers or not). Idle chitchat will drift back to work and what you've been blocked on is resolved in the discussion. Then you go back inside and do it again. NOTHING has helped as much as the "smoke break". The getting up from the keyboard, away from the work area to just relax for a bit and let everything you've been doing/planning get processed by your subconscious.
ReplyDeletePair programming has to be one of the stupidest ideas I've ever encountered.
ReplyDeleteYet, people endlessly talk about it and morons even pay cretins to give talks and 'consult' about such practices. No wonder the majority of software in the world is such low quality.
This is a really good insight, because it's important for all of us who actually want to build teams who are honest with each other to remember that there are many narcissists in the world who aspire to live by these Machiavellian rules.
ReplyDeleteFortunately for us, it seems, there are proportionately less of them in our industry. Nevertheless, they are there.
Having said that, I've found that many of the tenants of Extreme Programming work with my team precisely because none of us are Machiavellian pricks using each other for our own personal gain. We actually have a vested interest in helping each other out.
As far as pair programming is concerned, we don't require it, but I tend to use it a lot to help people out and teach them new ideas and techniques by working with them on real projects. For me, it's a pragmatic tool, and I've personally found other approaches to be a waste of my time.
Humans, while they can be selfish, are also social animals and many of us have a need to belong to a friendly group of people. Not only that, but most humans also have a very high capacity for empathy as well, which means there are a lot human attributes that support the ideas in XP.
In other words, you might need to throw out the bad apples before they rot the bunch.
"We ask time and time again why the mythical silver bullet is still searched for by those who have already agreed that it is a fools errand."
ReplyDeleteIn IT, the world is always changing. We need to adapt. The web changed and you don't create a website the same way you did back in 1996.
This is the same reason why so many universities sucks - they still teach us the "fundamentals" that were new in 1970!! Talk about relevance! Do we still develop in Cobolt? I am an experienced software developer that got pissed off by bad management where I work so I decided to do a degree in computer science with a minor in entrepreneurship. And what I find is how pathetic the university is at developing the skills that really matters in the industry to be productive!
"Why are proven techniques not mandated by management or agreed to by the workers who constantly complain about the current poor practices?"
There are a lot of managers with no relevant experience in software development, yet they make decisions with the theory. But theory isn't practice. Software developers are not good communicators. they are not listenned because they do not prove their points and stick to their ideas.
So... if there would be a team with good management and good developers, there shouldn't a difference between agile and non-agile.
In that sense, i agree with you that agile as a religion is awful!
Oh okay well then how about extreme management? If management thinks extreme programming is such a grand idea let them practice the concept themselves.
ReplyDeleteThere is always that job interview question asking if you are a happy and bright team player or an anti-social lone drifter who wants to do things your own way off in a dark corner away from everyone else. Management who prefer XP should ask themselves the same questions then we'll see how happy their are sitting on each others laps at the same desk sharing each others foul breath.