Saturday, February 27, 2010

Chuck Norris programming language

I've seen a few Chuck Norris programming posts, I thought I'd do my own about the Chuck Norris programming language.

Chuck Norris Programming
More fun Check Norris Facts

Here are the primary features:

* Chuck Norris doesn't need a revision control tool, all versions of the code are always available.
* Code in Chuck Norris is always optimal.
* Chuck Norris never dies.
* Chuck Norris can parse invalid XML
* Chuck Norris can divide by 0.
* Chuck Norris can compile syntax errors.
* Braces are for weaklings, Chuck Norris doesn't need them.
* Chuck Norris doesn't need Exceptions, he makes the rules and they get followed.
* If Chuck Norris Norris DID have exceptions, they could be thrown through a brick wall.
* Check Norris doesn't need Iterators, he's going to do everything once and at the same time.
* Chuck Norris doesn't kill processes, they get destroyed.

Any other features?

What are developers going to do?

I was explaining to a developer the other day how we didn't need a lot of the java code we where writing because there where tools that did these jobs better (or at least as well) that already worked. His response was (half jokingly) something along the lines of "well, if I don't write this stuff, I what am I going to do?".

This was a little bit of a shock to me as I assumed everyone on the team understood there where about 40 projects we couldn't do because we "didn't have the bandwidth" and management was not going to hire 40x more developers to do the work. Because I knew this, I've been spending a lot of time reducing the amount of manual labor we expend building software as well as trying to get us into the mode of reusing as much as possible.

What I didn't do is explain to the team that we aren't doing this to reduce headcount, we're doing this to be able to deliver more cool stuff faster and more reliably. The big problem we have (and it's not just my current team) is that as developers we get stuck in a rut of "this is how you do things" and step back and see that there are better ways of doing it.

A good example of where this has happened to me personally is with searching our sites. We had built a fairly robust solution with Lucene integrated with hibernate to full text index our data. It works well, it's fast, but it has a key problem which is: when the data changes behind the scenes we need to trigger a rebuild of the indexes.

A "solution" to this problem I've heard in the past (and even proposed myself) is "don't do that". You know... if your arm hurts when you throw a baseball, just don't throw baseballs. I've gotten to the point in my life where I realize that just digging in my heels are arguing in this manner really won't be productive. What I needed to do is make a couple of proposals.

So my proposals where:

Schedule a job to run every so often and poll for updated rows, then index them.
Write a sql server trigger make a remote call to the index server and trigger a reindex of changed rows.


write a SQL server trigger to trigger a remote re-index on our server. The thing that we missed was: Most DBMS's have a built-in full text search capability. Instead of building a bunch of stuff to workaround problems with our current solution, using the built-in full text solves the problem just as well (as far as we can see so far) and eliminates some problems with the previous solution.

There are some problems with this method, but it's a lot less work to keep things in sync.