The Importance of a Good Code Name

Yesterday I attended a meeting with a member of a clients configuration management team. Eventually the topic of “what do you want to call your source repository” came up and we all looked at each other and blinked.

Eventually a neuron in my brain triggered and I realised that this was an opportunity to pick a code name! Several good options were put on the table but for some reason the development team leader baulked at them and opted for something mundane and boring ().

I can never understand why people choose grey names for projects, its their opportunity to put some of their personality into the project, but more importantly a good code name serves several useful purposes. A good code name:

• is a short hand way to refering to the system.
• is great for starting elevator pitches to executive management.
• is a way of avoiding analysis paralysis on namespace naming.

If I have convinced you to create a code-name for your project, here are a few rules that I would stick to for .NET projects:

• Avoid acronyms, they look like crap in namespaces.
• Prefer a single word codename, two word tops.
• Make it easy to search and replace in code.
• Place names, people names and funny words make great code names.

Do you have a code name for your project? If not, make one up and just start refering to the project as that – see how quickly your co-workers catch on.

This is the life . . .

I decided to catch a slightly earlier bus to work today so that I could catch up on a few podcasts. The first one that I had scheduled to listen to was the SQL Down Under podcast. This one is something special because it has Dr. Jim Gray who has had a hand in products such as DB2, Oracle RDB and of course several generations of SQL Server.

The hard questions about why SQL Server 2005 was so late were asked, but also questions about the future. I find the possibilities created by the CLR in SQL and LINQ coming down the line truely facinating. Is SQL going to become a data-aware application server? What happens as boxes scale up – is the midrange getting close to being able to clobber a mainframe without a cluster?

Greg also made a really great point about the reason for getting involved so early in product release cycle. Basically it boils down to being able to avoid having to keep on top of the evolving technology without having a massive learning curve every time a product ships.

Anyway – great show Greg!

Follow-up: Coding for Testability

I got a few comments (3) when I posted up about coding for testability. Paul took the time to post a detailed comment which came out kind of mangled and then followed up on his blog. Paul extends the pattern, essentially adding a fair bit more code and structure – this is a good thing if you can keep it up, but I wonder if I did a spot inspection of Paul’s code whether he had used it uniformly ().

Actually – the main point that I wanted to make is what effect a simple change can have on testability. I also think that if you can be more surgical in which parts of the program you mock with test harnesses you can reach into different parts of the code. This helps you test specific things, but it also helps drive your code coverage up.

Heading down to Melbourne for the VDNUG Hands-on Day

I’m heading down to Melbourne on Saturday to speak at the Victoria .NET User Group’s Hands-on Day being held at Cliftons. Bill McCarthy and Peter Stanski were originally slated to present but had to pull out. The title of the session is:

CLR, VB and C# IDE and Major Changes

I’m probably going to do more C# than VB but I will be sure to show how to use VB to exploit the latest changes in the CLR. I’m looking forward it, I haven’t been to a Melbourne event since the user groups officially merged under VDNUG.