Sean's Musings as a Service

Sean's Musings as a Service

Thinking agile must hurt immensely

  • Published:
  • categories: agile
  • tags: agile, rant

Why is it that so many developers are immediately defensive when they are told that they should try to change the way they operate. When a construction worker is given a better hammer or a automatic nail gun they are quick to realize the benefits via immediate feedback and are able to assimilate the new tools into there jobs, assuming they are not state workers, they do not complain that they could nail plywood 5x faster or that they are less strained at the end of the day. However when I tell a developer that there are changes to their current practices that they can take to improve I am immediately met with a defensive posture. I do not enjoy placating developers and the hours listening and nodding my head agreeing that they are smart and their knowledge and experience is are useful. These experiences are useful, I will assume that your developers do not suck, and it is hard for a person to listen to you shatter their school of thought whether you have a logical explaination or not and not feel personally attacked.

Is it the culture “classically” trained developers who feel that they will lose track of the sense of ownership when they perform pair programming. Or miss the shock and awe when they get to unveil 2000 new lines of code that they pains-painstakingly worked on in isolation for the past three weeks and can brand as theirs alone, whether it works or not. Or is it just that developers tend to be socially inept and have a hard time taking constructive criticism? I have found myself on both sides of the tracks here and luckily have been able to make the internal realization that there is always someone smarter and more clever than me; I am willing to listen to criticism. I am not saying act on it or agree with but at least listen. Why then, are equally or more intelligent developers unable to accept that they are working in a bubble of their own ignorance, setting themselves up to fail, and can improve?

When I work with a team of so-called classically trained developers( here I mean water-fall, gant chart creating, box filled with dusty spec doc mofo’s ) they insist that they are god’s gift to this earth and that there coding skill is unique. Product manager/owner is the sultan of code his or herself, speaking directly through a higher power in Java, C#, or even worse WSDL… Where does a value map line up or come in here, oh yeah in the PM’s grand scheme they are the gate keeper, the judge. jury, and executioner of all that is product X. How can a sensible developer agree with such methods? Is it money, a cube under an AC vent/heater, or having a the kitchenette where Jodie brings in donuts every other Thursday? No it is the titles and the sense of ownership that these methods persist!

“Meet Kim she is the Lead Senior Architect of Tactile Response Widget Design”, the product manager remarked as he pulled Kim’s lease to draw here our of her cube. " Wow, you code buttons in THREE different colors!", says the well-impressed client mouth open in shock and amazement. “Well not exactly code, but I have written the high and low level specifications for 30 different iterations of button design and architecture, well over 4000 pages. We can show you a slide deck that I wrote if you are under a non-disclosure, but let me give you a hint, we ‘may’ have a new color and font coming out in next year’s patch, prepare to have your mind blown!”, the Lead Senior Architect of Tactile Response Widget Design Kim commented as the smugness settled into her stance.

So if I work under Kim, what do I think of her? If you don’t know already, ask a developer friend of yours what he or she thinks of their power point-architects, it is not that surprising. In a profession where self worth is defined by how elegant (there is a very fine line between elegant and obfuscated ) you can solve a problem in code, identify code & algorithm ownership, as well as claim that it was an obvious solution, it is easy to see how an architect can become a sixth wheel, sorry the fifth wheel was already taken we will come back to that. If you can’t code there is certainly a diner table short of a philosopher somewhere.

So what does this have to do with being agile, well the answer may be not as surprising as you think. The main tenant that I associate with agile is the ability to change and adapt to the changing world around you. All of the points that I have commented on, using a bit of satire and angst, are major sticking points in the culture of legacy product and teams unfortunate enough to have what I will call “legacy developers” in their midst. I have left the lion’s share of the issues untouched here, mostly so I will have more to rant about later.

btw the fifth wheel is that ass-hat who over designs a marshalling object factory for vehicles because he thinks that we may have the need for other objects that have 4 wheels and carrying capacity other than shopping carts for online checkout, f that ass-hat right in the a

Migrated: from blogger 03-July-2014

Reference: