A retrospective is the process of looking back on a previous activity to analyze and learn from it, so as to improve upon it the next time around.
This is not specifically an agile idea, but it is a great item to append at the tail end of an iteration to provide valuable feedback for the next iteration.
Once again, an agile practice stems from a common-sense idea that people just don’t think of.
I got an e-mail from a co-worker at work today with a link to an article by Martin Fowler. It’s a pretty interesting topic, though nothing earth-shattering.
As are a lot of agile ideas, this one discusses yet another common-sense topic about the relationship between developers and the business. Because business clients don’t always know what they want, and probably don’t know what is possible technologically to streamline their process, it’s important that developers take an active interest in the business process and domain that they are developing for.
Take a look at the article. It provides a lot of good points.
The creator of a podcast I subscribe to, the Agile Toolkit, has posted several podcasts on his site that are direct recordings of some of the conference sessions from Agile 2006.
One of the sessions makes a joking reference to the Waterfall 2006 spoof web site that I mentioned in a previous post.
Take a listen if you’re interested.
Wow. This is just phenomenal.
Phenomenal!
This morning, I was performing the occasional ritual of browsing through the blogs of people I don’t know, just to see what others are taking the time to write about. The cool thing with this is that, often times, the writer will link to somebody else’s blog, who will then link to yet another blog, etc. etc. and the chain continues.
So, this morning I came across a post about an un-aired WB pilot called “Nobody’s Watching” that was seeing a lot of popularity on YouTube. I watched the pilot and must say I really wish somebody would pick this up. Quoting the author of the aforementioned blog, “[The writers] come up with a sitcom that satires reality TV and the horrible state of the sitcom.” And I must agree, I was laughing out loud at several moments (and I don’t often laugh out loud to TV shows).
Check out this site to watch the un-aired pilot in its entirety.
I love the anonymous methods feature that was added to C# 2.0. I got a taste of this feature in college when I used Java (which refers to them as anonymous inner classes). Regardless, this is yet another feature to help developers write cleaner code.
For example, let’s say your application has a button that, upon clicking, shows an “About” dialog, which displays various information about your application (e.g. version, logo, etc.). Upon closing that dialog, you’d like to display a message box, telling your user that they just saw your “About” dialog box (because users like having to click a lot…).
In C# 1.x, you’d have to write the following code to accomplish this:
private void Button1_Click(object sender, EventArgs e)
{
AboutDialog dlg = new AboutDialog();
dlg.Closed += new EventHandler(OnAboutDlgClosed);
dlg.ShowDialog(this);
}
// separate method for handling the form close event.
private void OnAboutDlgClosed(object sender, EventArgs e)
{
MessageBox.Show("You just saw my About dialog!");
}
However, in C# 2.0, you can do the same thing using anonymous methods:
private void Button1_Click(object sender, EventArgs e)
{
AboutDialog dlg = new AboutDialog();
// .NET 2.0 changed the name of the event to FormClosed
dlg.FormClosed += delegate
{
MessageBox.Show("You just saw my About dialog!");
}
dlg.ShowDialog(this);
}
That’s it. Frickin’ sweet!
Ok, so there are a couple drawbacks that I’ve found while using anonymous methods. First, I’ve found that I cannot use the “Edit and Continue” feature in the Visual Studio 2005 Debugger. That is, I am not allowed to make a change in the method or anonymous method while stepping through the code — instead, I have to make my code change and restart the debugger. A minor nuisance, but still a nuisance.
The other potential issue is that, assuming the code in the anonymous method needs to be executed in response to multiple events, some developers may find themselves copying and pasting the code in several places of their application, thus ignoring the general rule of code re-use.
This second issue can be very subtle. It is a problem of design, and it is up to the developer to be on the lookout for it. In cases like this, the C# 1.x example would be a good solution that promotes code re-use.