The Methodology War

Sunday, 21 February 2010 by Kate Howlett
In the last six months - or since I started back at university - I have discovered a war about which I had no prior knowledge. In fact it is a war that many people don't know about. It is the methodology war...

During the last few years it has come more to the fore - in the eyes of a lowly, new, software engineer or computer science student yet I'm told the feud has been raging for many more years than that.

What has prompted this change? What has made more people aware of it? Blogging, that's what. Blogs are a used by a multitude of people to catalogue their daily exploits, to share their love of foodstuffs or books, to share their musings or to add their two cents to the war. For blogs are propaganda - the ones dedicated to a specific subject greater than the self that is. Obviously talking about last night's dinner party is probably just a blog about last night's dinner party. But opinion blogs are the propaganda of the wars raging today.

And this war is of a different nature. Every (wo)man is fighting for themselves. They may share a banner with others, they may have friendships with opposites numbers. But essentially, every person is an army, their size dictated by their number of followers. And no person is neutral. We have no Switzerland in this war. Everyone has an opinion, even if they don't share it. They know who they do and don't believe. The opinion war covers many topics - especially in software - but the Methodology War is most interesting I think.

A little background then:
Disclaimer: This is not a historically researched blog, this is just a musing รก la title ;)
The original way to develop software was brought over from other engineering disciplines. At that time not many people thought about a different way to write/create software. We took methods from known sources. And we saw that it was good ;)

However, later on, many people saw that is was not good and sat down and thought about what would make it better. The most cited example of how it was not good is the bridge example:
Software engineering is not the same as building a bridge.
Which is mostly definitely true. We're not building bridges. We're building software - stuff that is soft, malleable and changeable. A bridge should not be those things. Up-front design is very, very, very important in bridge design. Not so much with software design. So the thinkers pondered this and decided to come up with a way to develop software that reflected the changeable nature of software.
And thus Agile was born. Sort of. It probably took a bit longer than that but never mind. Now, I'm not sure whether one kind of Agile movement inspired another, whether people were already disagreeing with it in separate camps and the armies were created with no knowledge of each other or what. I just know that the Agile armies began recruiting.
And since that day the software world has known no peace!
So then. I suppose we should discuss the banners around which certain armies rally. The key ones are:
  • "Agile"
  • XP
  • Scrum
  • Lean
  • Formal methodologies

There are many more - if you can think of any biggies I've left out do comment and I'll add them in - but these are the really big ones. I've lumped all the formal methodologies in one thing because they're not the subject of today's post. But there are armies who dislike all this Agile nonsense I am sure.

To the propaganda then! Most people these days have a blog. Even if it's just one that's got four posts (like mine) or they started it years ago and haven't posted in ages (like mine) or if it's one that's updated everyday and has a thousand posts. Many people have them. And in software these blogs are used to impart wisdom, share opinions and - often - to rant. And a subject beloved of many is Agile. Why Scrum is wrong, why XP is too harsh, why Lean is too lean, why Kate's-super-cool-methodology is the only way to go (more on that in a later post ;). And bloggers tell everyone their opinions on this matter, waxing lyrical about the methodology of choice and creating a propaganda machine that the less knowledgeable learn from.

What are their weapons you ask? You can't have a war without weapons (sadly). At least here they're not very violent. Unless you're having your daily retrospective and someone is too honest and another coder is... anyway, a story for another time! Weapons! Well, the propaganda is the most important weapon. But the Principles are important too. Ahhhh the Principles. Every methodology must have them. Otherwise how do you know if you might win? How else do you calculate superiority? And of course the Methods themselves.

Interestingly, in this war, the weapons can be used against the army from which they originate. Not only can a proponent of an opposing army detail their excellent experience with Principle X (on their blog) they can bemoan their horrible experience with Principle Y. Thus people are turned off by this methodology. Or people can merely be turned off by experiencing the Principle or Method for themselves.

As my friend @azafred said to me the other day; perhaps the DDOS attack is the Atomic Bomb of the Software World. He may just be right. There *are* other ways to attack an army other than slander and flamewars. And these weapons are far more personal than a gun. Often soldiers in a war are drafted, not knowing about the subject, merely attacking those on the other side. When every man is an army they all know what they are fighting for and when they decide *your* army should go down they will attack you personally. Sad but true. Obviously this sort of attack is reserved for the fanatics, the evangelists and the downright mean.

Anyways, I fear this a war that will rage as long as there are software developers. So think wisely before you create your army. Read *all* the propaganda, be aware of the weapons of the opposition and decide which banner around which you wish to rally. And just have fun!

2 comments:

Unknown said...

And don't forget to ask your sys-admin / Operations Engineer to see which of those crazy methodology (s)he is willing to support. An Agile methodology with a 2 weeks cycle on a crappy product will be hell on an operation team!

Anonymous said...

Yeah, I totally hate it when the team is trying to complete a sprint and my project gets DDoSed into development hell by formal method zealots.