fuzzylizard

I have been working on my first ThoughtWorks project for about a month now. The first two weeks, I was doing performance testing on the application. For the last two weeks I have been trying to learn the application due to one of our developers resigning. This project is at the end of its development process and will hopefully be going live soon. As such, we are mostly just fixing bugs right now and finishing up a little bit of development.

Joining a project at the end is very hard. It is even harder when you cannot pair with an experienced developer. We have five developers on the project. This means one person is left out, usually me due to the other developers doing more important work and the developer that is leaving trying to finish some stuff up before going.

In this type of situation, pairing is an absolute. There is no way that someone can learn an application’s domain, its code, and the technologies used in the application without pairing with someone more experienced. it just isn’t possible.

However, with that said, I have to add that the way people pair also helps. One of the developers would jump around in the code and between windows, never slowing down for the other pair to catch up. This makes it very hard for the pair to keep up and to learn.

So far, though, it has been a lot of fun and a challenge. And I like challenges, so it’s all good.

I think the hardest part of joining ThoughtWorks has been getting used to all the traveling. I am currently working in Madison, WI, which means that I fly here every Sunday and fly back to Toronto every Thursday evening. Here are some of my observations so far:

* I don’t fit on all planes. Last week, I tried flying out of Madison to Toronto via Chicago. The plane from to Chicago was this small little puddle jumper with only 3 seats per row. Not only could I not stand up straight in the plane, my knees were bunched up against the seat in front of me.
* Air Canada seems to have more leg room then United.
* Large carry on bags do not fit on small planes. I bought myself a new rolling notebook bag yesterday to save my shoulder and lower back. It didn’t fit in the overhead luggage compartment so I had to store it under the seat in front of me. Thankfully the flight was only an hour.
* Madison has a very nice waiting area with leather couches and cumfy seats and wide screen T.V.s to watch
* Maneuvering two pieces of wheelie luggage through an airport takes practice and skill. Maneuvering luggage well is an art form.

I thought I would share a few of the things that I learned while going through Object Bootcamp last week. The first, and probably the biggest thing was the idea of memory equivalence. This can be show easily by also showing another thing that I learned which was how to use the Null-Object design pattern. This is a pattern that I have read about, but have never really seen used until now.

The Null-Object pattern is used to return a null object instead of a null. The former is better since it removes the chance of encountering a NullPointerException. The idea is to return an object that basically does nothing, i.e., its methods simply return default, useless data. The trick is in how to implement this object.

Say we have an email object that represents an email address and can send an email when the appropriate method is called; however, the email address may or may not exist. So instead of returning null, we want to return a null-object when we do a search. So here is our email object:

public class email {
  private String emailAddress;

  public boolean sendEmail(String message) {
    // send out email using Javamail or something
  }
}

Now here is the same class utilizing the null-object pattern, the trick is the static instantiation.

public class Email {

  public static Email noEmailAddress() {
    public boolean sendEmail(String message) {
      return false;
    }
  };

  private String emailAddress;

  public boolean sendEmail(String message) {
    // send out email using Javamail or something
  }
}

The sensible default is to always answer false (i.e., the email was not sent) when sending the sendEmail() message to the Email object. This way, it does what we expect and doesn’t break anything.

*Update:* ignore the following since, although it does make the code more readable, it breaks with the intention of the null-object pattern. As pointed out to me in the first comment.

Another cool feature of using the null-object pattern is that we can now write code that looks like this:

if (returnedEmailAddress==noEmailAddress) {
  // do something about it
}

if (returnedEmailAddress==null) { //do something }

This makes the code a lot more readable and understandable. Just by looking at the code, we can understand immediately what happened. The trick to this is that we only ever instantiate one noEmailAddress object. This allows us to check that the two references point to the same space in memory and results in a very nice equivalency check instead of having to use returnedEmailAddress.equals(noEmailAddress).

Talk about a small whirlwind. Yesterday was my first official day at ThoughtWorks. I started the day by getting up at 5am and going to the airport to fly to Calgary for a very brief orientation. Now I am in Chicago for 10 days of ThoughtWorks Immersion. Lots of fun, but the time has gone by far too quickly.

Right now it all seems a bit surreal. It has been six months since I first submitted my resume; I am having trouble believing that I am actually a ThoughtWorker now. I’m hoping to get over this in the next few days (or weeks).

The next goal is to relax a bit and enjoy the next two weeks in Chicago. Deep dish pizza here I come, yumm.

Ya gotta love a “company”:http://www.thoughtworks.com with a “sense of humour.”:http://www.youtube.com/watch?v=sjnxFyJT2I4

After a nearly two and a half month wait, I am no longer an employee at Environment Canada. I packed up my stuff, closed my accounts and turned off my computer for good today and walked out the front door for the last time as an employee. The reason for this leaving is that I am finally joining ThoughtWorks.

I have to admit though that this all seems a little surreal due to the long wait. I can hardly believe that the time has finally come to start work. The current plan is to fly to Chicago for training–ThoughtWorks Immersion–and then join a team and start working.

I really can’t wait to start and am definitely looking forward to working with other ThoughtWorkers and learning from them. And hopefully in some small way I can contribute something back and they can learn something from me.

Onwards and Upwards!

Apparently there is a bit of a “discussion going on between several ThoughtWorkers about the user of the term Agile.”:http://www.infoq.com/news/2006/12/debating-agility-at-thoughtworks It centres around the idea that Agile has become a religion and was started by Dr. Webber in a blog post in which he stated that he was an Agile Atheist. I am not going to rehash that entire discussion here as the preceding link does a much better job of this than I could; however, I would like to chime in with my two cents.

One point that is made at the end of the article is the following:

bq. If Agile religion exists, it seems to consist of a focus on strict adherence to practices without a need for understanding, combined with judgmental criticism of others - clearly ignoring the spirit of the Agile Manifesto’s “people over process,” values-driven approach. As another commenter noted: “When I refer to Agile - just the word - as you have in the title, I’m focused on the mindset, the spirit, not the practices.” There are in fact NO practices specified in the Agile Manifesto, or its accompanying list of principles.

I agree with this statement. I have seen and read far too many articles that centre solely on the practices of Agile and try to side step the principles. I read an entire marketing “article” by IBM that tried to sell Agile practices, completely ignoring the principles, in order to sell some high priced piece of software that followed those practices.

I personally don’t understand how one can implement Agile by simply borrowing its practices, that is like professing belief in a religion, but only following its observances. (Mind you, I think most religions are actually built on this principle so maybe the comparison between software development processes and religion is not that far off for.)

On one level, I have to agree that we need to remove religion, or better stated, zealotry, from computer science and software development. Discussions over why Linux is superior over Microsoft and why using open source software is the only ethical thing to do need to be put to rest. I am tired of hearing that I am less of a human for using proprietary software. Personally, I really like Microsoft Office 2007 and can’t wait till they implement it on the Mac.

On the other hand, I still consider myself a proponent of Agile and try to following its principles as much as possible. But even in my own limited experience, I have seen, that in order to follow the principles, you have to bend some of its practices. But I believe you can do this and still be doing Agile development.