What I've learned so far:

- Doug is sick (not mentally - he has a cold)

- It's Doug's birthday

- Doug is bald

The XML DevCon is nice because speakers can talk about whatever in the hell they want to.

We sang happy birthday to him, and then he announced that he's on some heavy duty cold medication that might have an effect on his coherency.

He's talking now about the concept that there is "only one application" (this is picking up from a previous thread at another conference), and that when you contribute an application to the Applicationosphere, "...it doesn't go away."

In other words, you need to:

- "Favor non-breaking changes whenever possible"

- "[A]dd, but never remove"

Good advice.

General, already quite familiar advice, but good all the same.

The rest was all code samples, which I will endeavor to copy down for you here.

Starting with the following snippet:

10 PRINT "I AM THE KING OF THE WORLD"

20 GOTO 10

Let's assume that you have different teams working on lines 10 and 20 (I admit I've been out of the trenches for a couple months, but this is still how people were doing it when I left, so I'll run with the assumption that things haven't changed).

What happens when your company hires a bunch of new developers and this happens?

10 PRINT "I AM THE KING OF THE WORLD"

20 GOTO 10

30 PRINT "I AM SO AWESOME"

If you know anything about coding, then you know that line 30 is screwed here. If you redeploy this application as is, customers aren't going to get the benefit added by the Line 30 Team.

What happens next is you ship the code off to the Philippines where twenty underpaid coders work day and night to fix the problem, eventually sending this back:

10 PRINT "I AM THE KING OF THE WORLD"

15 PRINT "I AM SO AWESOME"

20 GOTO 10

Doug didn't explain why this works, but I think it's because line 30 has been turned into line 15, which means it will get run before hitting the GOTO on line 20 (also, the Line 30 Team got fired for biffing it so bad).

This goes back to the idea that you can add, but not take away.

Think about what would happen if you did this:

15 PRINT "I AM SO AWESOME"

20 GOTO 10

Does anybody know what's wrong with this code? If you know your stuff, then you'll see that line 10 has been removed, and GOTO 10 is going to go...

...nowhere! That's right.

This breaks everything, and the interpreter is going to throw an exception.

Don't be the jerk who writes this code.

What you should take away from Doug's talk is this:

If 20 goes to 10, then make sure 10 is still there

Anything else is just sloppy and stupid, and makes you the asshole of your team.