So I keep being struck by the idea that there are lots of consultants and "teachers" and authors who push the methodology. But these same people are not really down in the trenches building software. I have to say that "Extreme Programming" strikes me as another example of people hyping yet another magic bullet. 

''A lot of people on Wiki are determined that this won't ever be true of XP.  Thanks for pointing out the danger.''

When talking about "methodologists"
GradyBooch makes the point that you should ask "What
proportion of your time do you spend on real projects?".
----
I had an immediate RudenessObjection to the first sentence in this response in AnOoMagicBullet:

''This is bizarre. ExtremeProgramming was derived initially from real world experience with a large, successful, program written in SmallTalk, and initially promoted by KentBeck, someone with a wealth of "in the trenches" experience.''

Clearly the original statement was made by someone that was both new to XP and new to Wiki.  Given the widening interest in XP (and the drop in signal to noise ratio that this inevitably implies) it is not at all ''bizarre'' that
someone should misunderstand some things about it, including the very important fact that XP actually breaks the convention that MethodologistsDontProgram.  

But the opinion of people who have just heard the rumors really does matter. Because the message always changes, subtly, with increasing popularity.

--RichardDrake
-----
A "programming methodologist" is an ExtremeOxymoron, even if you find one or two of them.
-----
Jerry Weinberg tells the story of studying a number of (very) large, failed software projects (i.e., projects that were over schedule, and were cancelled before shipping a product). If I recall the story correctly, 11 of the 13 failed projects had published their own methodologies. --DaveSmith

One of my funniest interview experiences was when I took my boss along, flew to N. Carolina to interview a methodologically "successful" project. After a long story, it turned out that the project manager got fired, the project got canceled, and the team refused to ever work that way again ... and the team lead who drove their working style proudly showed me the Process Quality award he had just been given, for "instituting a repeatable process."   I'm sure he never got the joke.  --AlistairCockburn


I think that even in the XP camp these stories should give us pause on how difficult it is for any of us to make progress with diverse, real world problems and the high quality reflection that makes true methodology possible.  To coin a phrase "Software is too damned hard..." (what else did that guy say again?).  --RichardDrake
----
Having met, talked with, and sometimes worked with 4 or 5 of famous European methodologists between say 1978 to 1985, I noticed that
they had all once been successful programmers, and part of their success was
doing programming their own way in their own projects.  The question is whether
one should share what one has learned and so become a methodologist.

--DickBotting

Of course one should - as long as there is genuine insight combined with an insatiable desire to keep learning.

--RichardDrake
----

Changing jobs invites reflection on past experiences. Reflection invites nostalgia, perhaps, but also reminds you of stories that are clearer from a distance than they were from close up.

Way back when I'd been asked to start up a team to incubate CORBA and Java at FirstUnion, I had the notion that the best way to make a technology useful to others in the bank was to actually, well, USE it. So I wanted to build a team that would write real, working components that other development teams could use in their real, production applications. But I had never run a software team before, and (thankfully) didn't know enough about development processes to know where to get started. I was lucky enough to hook up with JamesCollins, who came in on a contract to define our development approach.

Imagine my surprise when, after he'd been there about a week, I noticed him sitting in other developer's cubes, eyeball deep in the code, helping to sort out tricky Java development issues. I was surprised, and (I remember) even a little frustrated. This wasn't what I'd brought him in for. Sure, he was helping us past some problems that no-one else could have solved, but where was that going to leave us when it came to development approach?

You can imagine the rest. It was this time at the keyboard with other developers, solving real problems, that gave him both the credibility to introduce a radical new development approach (this was before I'd heard the term XP, we just called it the FourProjectValues), and also the opportunity to bring it into play in real situations on a daily basis.

I learned a lot of specific, applied things about writing software from James. But this lesson, about consulting in general and methodology in particular, was the most fundamental. -- BillBarnett


See Also GreatTeachers, CategoryMethodology, RollingYourOwnMethodology