Monday, August 18, 2008

My all-time favorite Ron Jeffries quote

From the NeverIsNeverNever page on the C2 wiki:

I know that if you agree NEVER to let the unit tests drop below 100%, you'll only do it that one time when you just couldn't figure out an incremental way to change all the deductions from negative to positive. If you agree NEVER to keep a task open for two weeks, you have a better chance of finding the way to do it incrementally, and that one time you'll make sure you've sucked every idea out of the universe before giving in.

When I say something should never be done, it should mean that you'll never do it unless you really have to.

And if you really have to, you'll ask everyone you know first so you still won't have to.

And if you still have to, you'll be looking over your shoulder scared to death that I'm going to materialize there and say "why didn't you just ..." and be RIGHT, and EVERYONE will know you're an idiot.

When you're sure that you'll be able to say "because X" and I'll quietly lower my eyes and say "oh" and de-rez back to wherever I come from ... then break the rule.

Then do one more thing. When it's over, and you've suffered - as you will - for breaking the rule, think back and figure out what you could have done, and learn the deeper meaning of NEVER.

Monday, August 4, 2008

No, no and thrice no!

Over at Coding Horror, Jeff Atwood has run off the rails and gone over to the dark side. He has uttered words that are indistinguishable from those that come forth from the majority of Corporate America Information Technology management. Don't believe it? Check it out for yourselves. I'll be waiting for you when you've read it.

Not being one to beat about the bush, let me offer this comment to Jeff's idea.

No, no and thrice no!

Since pastors aren't supposed to say naughty words, I am left with little alternative but to fire up some sarcasm and get to it.

There are so many things wrong with this perspective that it's almost impossible to know where to start debunking this foolish notion. After all, if quantity was all that mattered, then the Microsoft Vista operating system would be the best thing since sliced bread, the bee's knees and the cream of the crop all mixed in together and served with a cherry on top. Last I heard, it was seven shades of dreadful. (Or at least that's what I hear, I use Mac's at home and my employer hasn't moved past Windows XP yet.)

I've mentioned this before in this blog, but the system that I and my co-workers are trying to fix, is an eight year accretion of code. If quantity trumps quality then how come I can't find any in the system? There isn't any. I've looked. My co-workers have looked. And then because we hoped there was something of merit in there, we ran some automated code quality tests on the codebase and some of the modules on their own break the email system when the error logs are emailed internally. That's quite a lot of errors and not a lot of quality.

If quantity trumps quality, then how come the twelve line blank templated JavaDoc before each of the methods don't give me the warm fuzzies? It should. I mean, what's not to like about fifty percent of the source code in any randomly selected Java source file being empty JavaDoc? And broken JavaDoc with invalid JavaDoc tags at that. Goodness, I bet Jeff would love them. There's so many of them, I might ship him a few as we have so many of them to spare.

Now, don't get me wrong here, I think that the best way to learn to write code is to read a little theory and write a lot of code and throw it away. Then repeat. Read a little more theory and then write a bunch more code and throw it away again. Keep repeating this, as I have for about twenty eight years, and you'll be a fairly good programmer. It's not quantity of practice code that I object to, it's the inference that any code base can attain quality by just churning out code with no regard to quality.

Sorry. Ain't gonna happen!

You see, the ceramics example that Jeff gives us just proves that practice does help. There were items made by the "bulk" half of the class that were excellent, because the quest for quantity effectively forced the students to practice their craft. But the admission that not everything was of high quality shows the problem.

Any programming project is the sum of all the code that gets written for it.

By seeking quantity and taking a "quality be damned" approach, you may eventually have the quality that comes from practice, but that quality code will be on top of the early dross and a diamond in the mud, while still a diamond is still muddy and hard to appreciate.

So, may I suggest, as I have learned from experience, that quality comes from caring and practice and not as an accidental discovery within bulk code.

Friday, August 1, 2008

Men are just happier people

As I get ready to head off to our district's Men's Camp, allow me to leave you with another classic Internet funny. Enjoy!

If Laura, Kate and Sarah go out for lunch, they will call each other Laura, Kate and Sarah.
If Mike, Dave and John go out, they will affectionately refer to each other as Fat Boy, Godzilla and Four-eyes.

When the bill arrives, Mike, Dave and John will each throw in $20, even though it's only for $32.50. None of them will have anything smaller and none will actually admit they want change back.
When the girls get their bill, out come the pocket calculators.

A man will pay $2 for a $1 item he needs.
A woman will pay $1 for a $2 item that she doesn't need but it's on sale.

A man has six items in his bathroom: toothbrush and toothpaste, shaving cream, razor, a bar of soap, and a towel from M&S.
The average number of items in the typical woman's bathroom is 337. A man would not be able to identify more than 20 of these items.

A woman has the last word in any argument.
Anything a man says after that is the beginning of a new argument.

Women love cats.
Men say they love cats, but when women aren't looking, men kick cats.

A woman worries about the future until she gets a husband.
A man never worries about the future until he gets a wife.

A successful man is one who makes more money than his wife can spend.
A successful woman is one who can find such a man.

A woman marries a man expecting he will change, but he doesn't.
A man marries a woman expecting that she won't change, but she does.

A woman will dress up to go shopping, water the plants, empty the bins, answer the phone, read a book, and get the mail.
A man will dress up for weddings and funerals.

Men wake up as good-looking as they went to bed.
Women somehow deteriorate during the night.

Ah, children. A woman knows all about her children. She knows about dentist appointments and romances, best friends, favorite foods, secret fears and hopes and dreams.
A man is vaguely aware of some short people living in the house.

A married man should forget his mistakes.
There's no use in two people remembering the same thing.