Fog Creek Software
Discussion Board

The advantages of Methodology

In several XP orientated threads it seems that there are a lot of people who agree with most of the ideas in XP, but dislike its packaging as a methodology.  Some interesting quotes are:

"the last person that made us wear uniforms was Hitler"

This engineer has never submitted to dictatorial nonsense of any sort, no matter how sweet the stock options...

------------------------------------------------------------- Nat Ersoz

This REALLY IS an interesting socio-cultural phenomenon. Many of the quotes from XP proponents above are verbatim quotes from apologists for Communism and various cults. Probably fascism too.

------------------------------------------------------------ Hugh Wells

I think most people are missing the point, that XP is mostly a way to sell books, consulting, and conference appearances. There are some interesting ideas in the books. Not sure what the big deal is.
------------------------------------------------------------------- anon

It seems to me that they are argueing against the idea of having a methodology, rather than XP itself.

So, is there any advantage to having a Methodology?

I see the following advantages:

1) Team members can work together by establishing a common working practice and vocabulary.

2) It is easier for corporatations to adopt, because the structure of the team is already set out for them.

3) It is easier to initiate new members to the team.  Ideally each member of the team to have a broad knowledge of best practice, but it can be hard work getting your average graduate to work his way through code complete.  Some people prefer to just be told what to do.

4) It provides a standard for supporters to back, enabling them to raise the profile.

5) It makes it easir for mass market tools to be produced for supporting the methods.  For example, we are starting to see the emergence of Refactoring tools.  Sure, people have been refactoring for decades, but it is only since 'Refactoring' as a named phenomenum appeared that companies are starting to market tools.

Ged Byrne
Wednesday, May 8, 2002

6)  The further up the CMM a company is, the more often
it successfully delivers projects.

Johnny Simmson
Wednesday, May 8, 2002

This is a deeper subject than just software eng.  In the end, the evangelists have the responsibility for being didactic, and listeners must tear the evangelists' words apart.  But both should do it knowingly and with humor.

Wednesday, May 8, 2002

From Peter Drucker's "The Practice Of Management" (A book read by MBA-Types; the "Seminal Work in the field")

"There are three common misues of reports and procedures ... The second misuse is to consider procedures a substitute for judgement.  Procedures can work only where judgement is no longer required, that is, in the repetitive situation for whose handling the judgement has allready been supplied and tested.  Our civilization suffers from a superstitious belief in the magical effect of printed forms.  And the superstition is most dangerous when it leads us into trying to handle the exceptional, non-routine situation by procedure.  In fact, it is the test of a good procedure that it quickly identifies the situations that, even in the most routine of processes, do not fit the pattern but require special handling and decision making based on judgement ..."

  -- In other words:

  - Stories as Specs
  - Xtreme Programming Units of Measure
  - Two-Person Design Sessions
  - Test-First Design
  - Pair Programming
  - Re-Factoring
  - Single Integration Machine

-- These are all good things.  If they become "revealed truth" ... there's a problem.  (In my book, there is a big difference between best practices and methodology as revealed truth ... See Joel's article on Big Macs and the Chef for more info.)



Matt Heusser
Wednesday, May 8, 2002

For me, analysis/design methodology allows one to thoroughly attempt answer the who/what/why/how up front.  This can save considerable effort downsteam. 

Everyone has worked on a project that probably should never have been undertaken, and everyone has worked on stuff that was redefined several times.  In my experience, methodlogy can help to minimize these situations.

Wednesday, May 8, 2002

In my experience, methodology is there to help ensure you don't forget anything. If there are any number of ways to tackle a problem, the important thing is to choose one way and to do it. The next most important thing is to make sure you do it right.

Having a methodology also helps get everyone on the same page. If the methodology is known, comfortable, and it's weaknesses known, things should go relatievly smoothly. Of course, there's a fine line between comfortable with the weaknesses known, and comfortable and flawed.

That I think is the criticisms of methodology I'm hearing here. It's easy to follow it and blame the methodology when things go wrong. "But we did XYZ just like everyone else."

Hire good people and use it as a checklist. That's what I would do.

Wednesday, May 8, 2002

I like methodologies, really I do.  I really like them.  Some of my best friends are methodologies.  I don't have anything against methodologies, really, and if I had to guess, I'd guess methodologies really like me too.  Mostly.  Maybe.  Sometimes.

Nat Ersoz
Wednesday, May 8, 2002

There is method in my madness and for a small, yet considerable fee, I am willing to share that method with the first 22/7 respondents.

Simon Lucy
Thursday, May 9, 2002

Hire good people and use it as a checklist.
------------------------------------------------------------Mark Taw

I think a lot of companies think they can hire average people (cheaper) and use a methodology.  As far as I can see they just waste money.

Ged Byrne
Wednesday, May 15, 2002

Statistics dictate that the average company can
only hire average people.
They have no other choice.
So perhaps they need the methodology: to run a
profitable company with average people.

Friday, May 17, 2002

Ged, no, my querying of XP has nothing to do with an aversion to methodology. I'm a methodology guy. I might reply in more depth later.

Hugh Wells
Saturday, May 18, 2002

At the risk of sounding like I'm saying "me too", uhh, me too.  I accept that methodologies are necessary.  Everyone has some procedure for getting work done even if they are not formalized. 

I think its important for an engineering team to formalize their methods.  My main reason for doing so is that if you don't do it, someone else will do it for you.  And then you're headed quickly into the dilbert zone.

All that is really necessary is for you do "say what you do and do what you say".  It is as simple as that, or at least I want to keep it that simple.  Formalizing methods (that is documenting them) is really an insurance policy against human weakness.

Anyhoo...  I could ramble on for hours...

Nat Ersoz
Monday, May 20, 2002

*  Recent Topics

*  Fog Creek Home