HMK's Spurious Thoughts Biased / Nicht immer ausgewogen

Dave Astels: Why your code sucks.
Yup, my code sucks. But I try hard everyday to make it suck less in certain areas.

Ron Jeffries: …when I refactor, it is without regard to the “big picture” of the system, or even of the code.
By letting loose of understanding and focussing on rote behaviour, I actually gain some minor understanding of a small part of the system, thus making progress in understanding of the complete system. One small refactoring/step at a time.
A very useful strategy when dealing with a large base of legacy code.
Interesting enough, letting loose of understanding requires a lot of courage and confidence.

Rachel’s Place: …form is unimportant, there is no right way to write a story and writing them is not the important part. What is essential, is that a conversation takes place between customer and developer.
An honest, frequent, ongoing, two-way conversation.

Looks like there are others out there pondering the idea of automatic persistence in desktop applications.
Implementing a UI enabling non-developers deal with versioning will be a real challenge.

Some great thoughts on well, as the title of this post implies, Zero Defect Development (via And Another thing).

Some more material on testers & developers:
Brian Marick points to Bret Pettichord‘s “Testers and Developers Think Differently“.

Bob Congdon mentions Steve Bourne (author of the Bourne Shell) was using a set of C-macros which allowed him to code in an ALGOL-like fashion.
During the mid-/late-80s I was “famous” for using a hand-crafted PASCAL.H header file which made my C-source code look like PASCAL. Of course, this was just ridiculous and made it much harder for us to use any source-code browsers etc. which almost always barfed when trying to “parse” our “pascalized” C-code.
From today’s point of view, my only excuse is that I was way too young back then.
Anyway, to close on a more serious and less reminiscent note: Of course, using macros to disguise one language as another is bullshit. If you keep your methods short (because you’re refactoring mercilessly, don’t you?), a new and potentially unfamiliar syntax shouldn’t get in your way.
Syntax doesn’t matter. Writing bad code is easy. Writing great code is hard. Doesn’t matter what language you’re using.