Darrin Chandler said: >> At this point I'll add something else. Great coders will do fine with whatever methodology. Bad coders will do bad. Great coders see the value of tools and use them appropriately. Bad coders follow a list of rules without knowing what they mean or how to apply them and get poor results. <<
Heh - took the words right out of my mouth. My field is embedded; the borderline between hardware and software. This means that software Must Not Crash - a failure can result in lawsuits. I've had many conversations about methodologies over the last three decades - back in the 70s I had a hard time convincing my seat-of-the-pants assembly-programming colleagues that structured design wasn't just a fad, and that spaghetti coding did not mean their creativity was stifled. More recently a manufacturing company took me on to help establish a Right First Time culture; they'd finally understood something I'd been preaching for years. I failed, I'm afraid. I knew I was in trouble when the internal project leader insisted that every Boolean be explicitly tested for equality with either TRUE or FALSE. I eventually walked. For the record, my view is that UML is flawed in the same way that flowcharts were flawed - the stickman diagrams never stay in sync with the production code. However, there are some good points buried in there - mainly to do with understanding the requirements (Use Cases) before doing anything else. Agile and Extreme programming both have elements of good sense, but tend to be obscured by dogma (IMHO). There are many others (the Personal Software Process is an interesting one). OO is again sensible, indeed mostly indispensable, but again gets obscured by its ties to C++, which is a deeply flawed language. Seems like most methodologies get corrupted by semantics. The only "methodology" that I whole-heartedly embrace is defensive programming. Beyond that, my approach amounts to a set of best practices (design before coding; avoid globals; communicate only via well-defined channels; break complex things down into a collection of simple things; synchronism; treat debugging as an admission of failure; etc etc). I get good results, but while customers appreciate these results and often ask how I do it, their eyes glaze over when I try to explain. Ho hum. Nowadays I sum it up in one word: "Dijkstra". He da man. Steve http://www.fivetrees.com