GenXJamerican

Scott Hanselman posts a number of great tips for  improving development teams.  The technical brown bag idea is one we’ve been following at work since the spring.  We call them “learning lunches”, and they’ve proven to be an excellent vehicle for knowledge transfer, as well as connecting different offices of the company.

At my current employer and the previous one, I’ve tried to promote conferences, off-site training, and .NET user groups.  Getting the staff to attend them has been more of a challenge here than at my last job.  They’re all excellent ways of keeping technical skills sharp as well as networking opportunities.

Now that we have a new CIO at work, it will be interesting to see to what degree he’d buy in to some of these ideas.

This question comes up rather often in my job, and this post by Adam Turoff answers the question by including “when” as a variable.  In short, the sooner a project needs to succeed, the less likely it is that a rewrite will succeed.

Whenever I come across an application that isn’t designed or implemented as well as it should be, I’m biased in favor of rewriting the application.  That approach tends to meet resistance because the “when” is usually very short.  Refactoring is a good fallback option, but only if the application is relatively current.  My desire to refactor single-tier classic ASP is nil.

This error message started showing up during testing of some code changes I made to an application.  It took me awhile to figure out precisely what the problem was because the top of the stack trace referred to this:

System.Activator.CreateInstance[T]()

I found this post rather useful in diagnosing the problem.

I needed a T-SQL statement to get the created date of a couple of tables as part of a project. One of my colleagues came up with this query:

SELECT create_date FROM sys.objects WHERE type = ‘U’ AND name = ‘<tablename>’

It works in SQL Server 2005.

The SQL Server 2000 equivalent is:

SELECT crdate FROM sysobjects WHERE xtype = ‘U’ and name = ‘<tablename>’

His top three preferences in brief:

• internalized discipline over externally-enforced discipline
• coaching over enforcement
• collaboration over direction

Miller does the best job of explaining his third preference.  Providing the rationale and context for a course of action gives a developer input and an opportunity to buy into an idea.  The success of this approach still depends on the having the right people.  I follow it with my own employees as much as possible.

Jeremy Miller asks that question in this post.

I haven’t had a chance to use it on any projects, but I really like the idea of customer-facing tests. Miller describes them very well as “executable requirements”. The comments highlight a number of alternatives to Fit, including FitNesse, Green Pepper, and ZiBreve.

From the comment volume on Miller’s post, it seems that only the specific implementation of Fit is on its way out. The idea looks very much alive.

One of the FxCop rule violations I found in one of my projects had to do with IDisposable not being implemented.  My search for examples of how to resolve this yielded a lot of helpful links, including these:

• An MSDN article on correct implementation of IDisposable
• A older CodeProject article on IDisposable that takes an odd shot at unit testing
• A newer CodeProject article on IDisposable and the dispose pattern
• A Channel9 discussion on IDisposable

I came across this James Avery post via Mike Gunderloy’s blog.  Avery attempts to make a similar point to one Martin Fowler puts forward about the best developers moving away from the .NET platform.  Beyond the sort of anecdotal evidence I’ve read, I don’t see much abandonment of .NET as a platform.

When I read this post by Dave Laribee, I decided that Avery missed his point.  The point of ALT.NET isn’t as a bridge to a different set of tools, but to recognize two things:

1. The best solutions on the .NET platform won't always come from Microsoft.
2. The best ideas from other software development communities can work very well on the .NET platform.

I learned an annoying lesson about these late last week.  I’d created the dataset by dragging and dropping the necessary tables from SQL Server in Visual Studio 2005.  Then I added a query to one of the tables that didn’t include every one of its columns.  Unfortunately, a number of the columns my query didn’t return didn’t allow nulls.  I ended up modifying my query to include those columns, even though I don’t use them.  I didn’t try removing the columns from the dataset, but that probably would have worked too.

Scott Westfall, a member of the SlickEdit development team, weighs in with three “theorems of programming languages”.  The second theorem (If programmers do not understand a piece of code, they will either break it or rewrite it.) is definitely, and painfully true.

There’s a Codeplex project that enables developers to use their Subversion clients with Team Foundation Server (TFS). It’s certainly an interesting project, though I don’t quite grasp the rationale. TFS is really expensive, so if a shop can afford it, they can afford Team Explorer too.

I found out about initially via TheServerSide.NET.

This piece by Martin Fowler interests me more for his contention that the best technical leaders are abandoning .NET than for what he writes about Ruby. It’s the sort of argument that seems true because anecdotal evidence seems readily available.  I’d be interested to see if there’s more quantitative backing for the assertion.

Some poking around on Google did reveal at least a couple statistics:

• Computer language use by projects in SourceForge (9/2000-2/2006)
• Programming Language Popularity

Apparently this is where Visual Studio 2005 stores connection strings when you add strongly-typed datasets in an application.  Even though I had an app.config file and I’d changed it to point to a new database, I was still getting SqlExceptions when I ran my unit tests.  I just didn’t know the old value was still stored in Settings.settings and needed to be updated.