Creditable Methodologies

WhenXpFails asks: what is the extent to which all CreditableMethodologies are based on the values of Simplicity, Communication, Feedback, and Aggressiveness These values being particularly associated with ExtremeProgramming. First off, what [other] methodologies are creditable, liked, and/or used in the opinion of Wiki?

Thanks for asking. I can't speak for Wiki. RonJeffries, SpeakingForBoskone?:

I find a lot to like in the Spiral Model. It is about risk reduction, what we call WorstThingsFirst, and about learning.

SEI/CMM works in my experience, I just wouldn't want to live there. It has too much management, too much overhead for my taste. But I have seen it work.

Doing the SEI's PersonalSoftwareProcess would be better than nothing by a long shot. It's about knowing yourself, which is key to being good at anything.

Cleanroom has produced some good software, and seems repeatable, but I'd rather spend the money on cars.

Personally I think that most well-thought-out methodologies, applied thoughtfully, can produce good software. I believe that most of them do not have the ease of XP, the predictability of XP, the openness, the pleasure of being in them. I believe that most of them are more expensive. I believe that most of them focus more on complexity and are more likely to result in complex final systems.

I think most methodologies are based on fear,

I remember that one of the old guys, Parnas, Dijkstra (EwDijkstra) or someone else, said that methodologies are based on fear. Does anybody know the correct source? -- FrankGerhardt
I know KentBeck said that phrase - does he count as one of the old guys yet?

mistrust, isolation, conservativism. Plan that your developers will quit in the middle of the project. Assume that the programmers can't design or will hack, gold-plate, etc. Try to get it as right as possible the first time, because there won't be time to make changes. Lock in the user/sponsors to requirements as quickly as possible. Try to make it so you can replace anyone, and hire the cheapest people possible, sitting anywhere in the world. Oddly enough, people get software out anyway. And they do quit in the middle of the project, hack, gold-plate, make last-minute requirements changes, sit anywhere in the world, shorten delivery times. It's actually astonishing.

Could it be because software is really easy after all?

Seems to me that traditional methodologies are designed to keep customers and managers from getting the jitters. Developers buy in, basically because we have no other option and also because many of us like rules. So much of it seems like magic: "If you do this, this, and this.. good things will happen. If bad things happen, you just didn't follow the rules closely enough." Time to get out the whip and drape it over your back (or just make more rules).

Methodology needs a good healthy dose of empiricism.. a methodology should be considered good not because it massages egos, or has good marketing, or a good theory behind it, but because it gets results. And above all, TheyreJustRules. Rules seem to be the last things that are questioned at times.

-- MichaelFeathers

CategoryMethodology