At my previous job we pair programmed because we thought we were doing XP. I could go on and on about why we weren't, and perhaps I will in another post as an example of what not to do, but I won't. I want to write about the paring area and one mistake we made: two keyboards and mice at each station. Don't do that. Here's why.

So I figured out how to add captchas to Drupal, so I'm reviving the site. It never really went away, as I was working on replacing it when I decided to spend a little time looking into captchas for Drupal.

So, now you'll have to pass a captcha to enter a comment, send me a message, or request an account. Woo hoo, mark one against the spammers.

I'm shutting down this site and moving my blog back to blogger.com. The lack of captcha support in Drupal has made maintaining this site unmanageable. I could force commenters to log in, but there doesn't seem to be captcha support for new members either, so I've got thousands of bot produced comments and pending accounts.

Thanks all you spambot writers. You're the scum of the internet, and may a yak with a thousands fleas bed your grandmother.

I never intended for readers to not be able to comment. It's my unfamiliarity with Drupal that caused the problem. I want comments. I intend my blog entries to start discussions not as a way to disseminate my infinite knowledge.

So, if you see this, please comment. And please leave comments on my other blog entries. It should all work now.

I was reading these posters and the one on simplicity made me think. It brilliantly summarized it with a simple concept: do the simplest thing, not the simplistic one. But what is the difference?

Rules of Simplicity:

1. Runs all the tests
2. Says everything once and only once (DRY)
3. Expresses all the ideas you want to express
4. Minimizes classes and methods

Mike Bria (mbria) had an tweet the other day about iterations and why we prefer them. Iterations provide two primary benefits over non-iterative development. In no particular order:

• Planning adjustment
• Customer feedback

The Open Closed Principle (OCP)

The Open Closed Principle (OCP) states that a system should be open to extension and closed to modification. In other words, it should be easy to add new functionality by not changing existing code. If you program to interfaces, it is much easier to follow the OCP.

Calculator No OCP

Let's build a very simple calculator.

class Calculator {
  int add(int x, int y) {
    return x + y;
  }
}