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

Reply via email to