My task for this week is to design a directory structure for source control. Next week I start a month of creating a build machine.

Yes Helen, I'm going to say it again. Another reason why I like working here.

My initials are SEH (Simon Edward Harriyott). SEH is the TLA for Structured Exception Handling. What do your initials do?

Unit testing is just plain inspired. In the old days, developers didn't really like testing. Someone must have had the idea that developers would like testing if they could do it by writing code. Testing code by writing code? Sounds far fetched, but it works.

I'm using NUnit and TestDriven.NET, and it has saved me some time and effort already. I used the Whidbey refactoring tool to extract a method, and lots of tests suddenly failed. The problem was with an original private member which should have been a parameter, but wasn't. I made it a parameter, and all the tests worked. I don't know how long that would have taken to locate without the tests.

I've just started using XPath, and I've found a really useful tool for working out paths.

This post is so off-topic, I'm not even going to write it.

A couple of my colleagues have brought up the subject of this weblog in conversation with me this week. I knew at least one person from work has been reading, as our network's IP address shows up in the server logs, but I didn't know who, or how many. Anyway, the first conversation was brief and friendly. The second conversation was different, in that I was asked for assurances that the details of the top-secret work I'm doing remain top-secret, and that my colleagues wouldn't easily recognise themselves from what I've written.

To clarify, I have some mental guidelines I use when posting:

1. Not divulging company secrets
2. Not slating anyone
3. Not intentionally annoying anyone
   
4. Generally not mentioning people by name

I use the word generally, as I've mentioned names when they're clearly not going to mind, like Robert Scoble (who thrives on it).

I hadn't given the "easily recognise themselves" much concious thought, and it's an interesting point. I almost totally agree. As an example, the last post I wrote before this discussion starts by mentioning a conversation I was having with "a couple of colleagues", and I then went off on one about the finer points of the word "reuse". Clearly the two colleagues know who they were, and can identify themselves. Equally clearly, the others in the room can identify them too, as they weren't talking, and we were. The point of the post was about reuse, not about the colleagues - it doesn't matter who I was talking with, it was just a handy way to start the paragraph.

As you can tell by reading what I've written in the past, I don't give a whole lot of thought to what I write, and so I won't promise that phrases like "a couple of colleagues" won't happen again. What I can promise though, is that I won't give out any company secrets, I will ask permission before posting any company related announcements, I will not slate my colleagues, and I won't mention a colleague's name without their permission. I will also delete any risky comments.

More importantly, if anything I write upsets anyone, or someone is mentioned in a way that they are unhappy about, I will change it at their request.

Had a discussion yesterday with a couple of colleagues about using somebody else's code. This all started after I had agonised over a design problem, and come up with a nifty solution, and written it in the spec. One of the others said something like "Half of that seems to be like some of this Microsoft application block, maybe we should use that."

So I spent all morning looking at the application block, trying to work out what it did, and what the generic terms actually meant. To use this application block in our application would have meant taking out some of it, and adding something else to it. I suggested that this wasn't really "reuse", as it changed the meaning of the original code. This was countered with the point that if the code has been written already, why rewrite it?

Having slept on it, it seems that the two extremes of reuse are:

1. This existing code does exactly what we need, so we'll use it.
2. This existing code does the opposite of what we need, in a different language, and on a different platform, so we won't use it.

I reckon most reuse "candidates" lie somewhere between the two. There's a point at which something reusable becomes more trouble than it's worth. If it requires too much changing, then it solves a different problem than it was being considered for. If the existing code or design requires too much changing to use it, then using it is upsetting the original purpose of the project.

On the other hand, if the code inside the module is well written, and easy to read and understand, it may be a trivial task to bend it into the exact requirement. Identifying quite where the tipping point is involves the skill of a talented developer.

The exception handling application block (in the context of my current project) seems to be extreme number 1, which is fantastic. It just does it. Include the assembly, set up the config file, and add a line of code in the catch block. Bish bash bosh. This is what I would call "reuse". I'm not sure what to call stuff between this extreme and the tipping point though. What is the maximum amount of change a code module can undergo and still be considered "reusable"?

Well, for me anyway.

My first job was C programming for a company that had no internet access. If I needed to learn something, I looked in the manual, or asked the two other developers.

My second job was MFC programming for a company that did have internet access. If I needed to learn something, I went to codeguru, or deja news to get some starting points.

My third job was all sorts of programming for a company that had better internet access. If I needed to learn something, I used MSDN and Google.

My current job is C# programming in Whidbey for a company with fast internet access. If I need to learn something, I watch telly.

Went to lunch yesterday with the team I work in, and afterwards I realised that there was no moaning. Either the people aren't moaners, or there isn't much to moan about. Another reason why I like working here.

Yesterday someone was looking on this site for a Glassmatix demo download. I've just asked one of the other developers, and although there isn't a Glassmatix III demo available for download, Glassmatix.NET allows some free estimates before signing up properly.

A little different to Wednesday's adventure, in that I knew everyone at the first Uckfield geek dinner, and there were no astrophysicists.


It was really jolly, despite someone asking what the difference was between generic code and reusable code. I think the nearest we got was that generic code is reusable, but reusable code isn't necessarily generic.

Again, the food was good, but in a different way. We got through 3.5 kilos of mussels.

A couple of days ago, I noticed that there was a geek dinner going on in London. I'd already booked mine, but as I knew everyone going, I thought it might be cool to go to one where I didn't know anyone.

It was cool. I've just got back. I met some really interesting people, including an astrophysicist (just a day job), someone who got his last job from an IM conversation, and someone who (amongst other things) has been asked to measure the height of biscuits to the nearest thousand of an inch. I sat opposite Frank Shaw, who brought along his tablet PC, with detachable keyboard. Nice. We discussed podcasting, the future of the media,

What I particularly enjoyed was conversations about things I've been reading on the web, with people who read the same weblogs as I do. They've met Robert Scoble. That doesn't seem to happen in Uckfield. I get asked what a blog is. My wife is starting to understand though. She asked if we were going to Apple-Mac-Donalds.

It seems funny that I have more in common with a table full of strangers than some of my closest friends.

Oh yeah, the food was good too.