I'm sitting on the train ready to return to England, my Wi-Fi detector says there is a wireless network but alas my computer can't find it. The meeting itself was a success but hard work when English is the second language of everyone else at the table. You have to be careful that you really understand what is being said. Plenty of white board pictures help. The funny thing is acronyms - it was a technical meeting so they were abundant but again the language differences play a part. For example, IVR (Interactive Voice Response) is SVI (Server Voice Interactive) in French.

The rest of the trip has had some ups and downs. Eurostar is excellent, almost a hop-on hop off service which beats waiting in an airport for a couple of hours. There is still immigration and customs. In fact I almost missed the out-bound journey because I didn't take passport checking into account.

I don't know Paris at all well so on arrival I tried to get a cab to take me to the hotel. The cab driver wouldn't take me though - too close. So he gave me directions: "turn right at the second set of lights, walk until you get to a bridge, turn left and its down that road". I set off in the direction he pointed and tried to follow his instructions. Well it turns out you need a bit of confidence to walk for a mile or so in a strange city without even knowing if you are going in the right direction. I made it to the bridge and checked the street sign - it wasn't the same street as the hotel address. At this point I bottled and hailed a cab, gave the driver the address and he said "ah, its just on this street" whilst giving me a strange look. He took me and I'm glad he did because it was about a mile "just down the street".

The hotel was a typical Paris affair - a converted building with creaky lifts and tiny rooms. Only just enough room for the bed in fact. Cosy I think they call it. The major problem was the lift shaft was right next door. See how much sleep you get with one of those going all night. The following morning I did actually walk all the way back to the station. I was planning the hail a cab but I couldn't find one until I reached the station.

With the meeting over, the train left the station half an hour ago; I'm now watching the French countryside hurtle past at 160 miles/hour wondering how long the battery life in my tablet is going to last. I just wish I had some network connectivity because it's been two days and I'm getting withdrawal symptoms. I just need to check my mail, read some blogs and see if I've had any referrals, then I'll be happy again.

As a separate note, I have a Tablet PC (bought mainly because of Robert Scoble's evangelism) and I find it funny that wherever I go I have to give a demonstration (closely followed by "Ooh, I love it. How much?". This trip was no different and I'm pleased to say that the handwriting recognition works even when I write in French. Also, One-Note is rapidly turning into a killer app for me - you can doodle in meetings using all the colours and pens provided to create some really great art.

I have a business trip to Paris tomorrow and Wednesday. This is a new customer who has some pretty cool ideas on how they want to use our products. They are very knowledgeable about the issues and technology involved so it should be a fun meeting. The challenge will be to satisfy their requirements within the constraints of our system.

Travel time is approximately two hours, much quicker than flying. I don't suppose EuroStar has fitted their trains with wireless hot-spots?

You may remember a few weeks back when I signed up for a Microsoft ISV Buddy. Well last week I got an email to put me in touch with mine. His name is Gaylon Blank and he's a dev lead in Microsoft human resources IT. It's funny, of all the software that Microsoft write it never really occurred to me that they would be writing their internal software systems. Obvious when you think about it though.

I think Gaylon is a pretty good match for us as we both have similar goals - trying to integrate new Microsoft products into our own offerings. Both of us are using Office Web Components and both are trying to work our how SQL Reporting Services can help.

With all good partnerships I hope this to be a two way street. We just need to work out what part of town it's going to be in.

For some reason I've found other things to blog about recently and have been ignoring Yukon. I was going to get around to writing about partitioned tables but there is no need now. Kimberly Tripp has released a fantastic paper on the subject:

While getting ready for the PASS Community Summit in Orlando this week (where I plan to talk about SQL Server 2005 Partitioned Tables/Indexes), I realized we were close but not quite ready to release the post-beta II whitepaper on MSDN.

So, in preparation for PASS we decided to post a pre-release of the partitioning paper here.

(via Kimberly L. Tripp: Improving your SQL skills)

Chris Rathjen has a post requesting information on how we deal with branching in change management so I thought it would make a good post subject.

At Exony we use Perforce as our source control system for two reasons: it's wickedly fast plus the branch and integration features are excellent. It is similar to SourceSafe in that the repository is structured much like a file system. We have a number of products that use internally developed shared libraries and third party SDKs. The tree on the left of the diagram below shows how things are structured. The right hand side shows the version lines with branch and integrations.

Each product or library has a folder which contains sub-folders representing available versions. All new development happens on the main branch. The nightly build scripts will attempt to integrate changes into the build branch (orange arrows) and then rebuild. If, for any reason, the build fails then the integration is rolled back. This ensures the build branch is always in a build-able state. Perforce change sets come in handy here because you can either commit or revert them based on the build outcome.

When it's nearly time to ship we branch the latest build branch into a "QA" folder (green arrows). This is the v1.0, v2.0, etc folder. This is the build that gets QA'd before it goes out of the door. Any fixes are still made in the main branch and once the nightlies copy the code into the build branch, we do manual integrations into the QA branch. This way we can verify that nothing major is going to de-stable the QA line.

After a release any fixes are made in the correct versioned branch before being reverse integrated back to the mainline if they are still relevant there (not shown on diagram).

Also, every time a build script is run the file versions in that branch are labelled with the build number. That way we can go back to any build on any branch if needed.

The third party SDKs, e.g. Microsoft SOAP or MSXML4, are also stored. These third party folders only contain headers, libs and DLLs used in the build process as there is no reason to store additional binaries such as CHM files.

Sharing code is also based on branching and integration (red dotted lines). Once a shared library is released then its actually integrated into the relevant product mainline. That way we isolate the product from any changes that may be happening to the shared libraries or any other product.

Overall the process works well and we haven't had any build related late nights since implementation (although there have been a couple of product related ones). It's nice to be able to hit a button, grab a coffee and wait for your product ISO to drop out at the end ready for burning onto CDs.

According to this survey, my personality type is The Discoverer: "Your distinct personality, The Discoverer, might be found in most of the thriving kingdoms of the time. Your overriding goal is to go where no one else has ever gone before. Regardless of the number of available natural problems to be solved, it is not unusual for you to continually challenge yourself with new situations or obstacles that you have created. You are an insatiable explorer of people, places, things and ideas. You thrive on constant change and anything new or different. On the positive side, you can be creatively rational as well as open minded and just. On the negative side, you might be an impractical and indecisive procrastinator."

Sounds about right...

(Link to survey via Sells Brothers -- Chris's Home on the Web)

So you spend the odd evening and weekend playing with the brand new technologies emerging from Microsoft. Whether it's Yukon, Whidbey or Longhorn, there is plenty to mess around with. The more you play with these tools, the more you can dream of new ways to deliver exciting products in next to no time. Life is rosy.

However, we all need to pay the bills and that means going to work. Work is not about dreams, it's about delivering real solutions to customers now. Here is where the misery starts. You can't actually use these tech previews and betas for production code so you have to do things the old way. The old way is no fun. It's depressing and we are still at least a year away from a more pleasant life. It's not that the current tool set is bad, in fact it's great. Compared to the new versions, though, the difference is immense.

Personally, I think it's worse as I can't see any of our customers (apart from one very progressive one) upgrading to Yukon until it's been on the shelves for at least a year. In fact Cisco ICM is a product we depend on and their recent release has only just caught up with SQL Server 2000. Understandably there has to be a business benefit for them to upgrade. Maybe there is but at the moment all I see is developer benefit.

I talk primarily about Whidbey and Yukon as I'm not even going to look at Longhorn until it's a bit more tangible. Blog land is full of posts wondering if it's worth using WinForms for development. In fact Microsoft has recently been on the offensive trying to persuade customers that WinForms is not dead.

On a final note, I do actually like what Microsoft is doing with tech previews. It helps me align my architecture and development plans with theirs. It just makes going to work a bit of a drag in the meantime.

I was on the verge of posting something last night that I'm glad I didn't. I was angry and had a lot to say. As it turns out, I feel differently today. I think there is a lesson here - posting to your weblog is much like writing an e-mail. The same golden rules apply; primarily - don't hit the send button when emotional. You might say that it's easy to change an article later but people will have seen the original and as Scoble points out: your original words will live forever in the various search engine caches.

I have to admit I'm one of the people that Rob Caron was helping out this weekend. With living in the UK I find it second nature to set the system locale to 'English (United Kingdom)' whenever I do an installation. On this occasion it turns out to be fatal when installing the Team Foundation Server. The main effect of which is that the installer will fail to create the correct ADAM structures.

After reinstalling the application server I was able to connect to the Team Foundation Server and create Portfolio Projects; but during creation it failed to create the corresponding Sharepoint site. After checking that I could access the Sharepoint Central Site (administration page) I remembered I hadn't changed the locale on the client computer. A few clicks later and everything is now working. I just need to work out how to delete all the failed Portfolio Projects from the system.

I haven't spent too much time looking at it yet as the 8 hour time difference to Redmond means support from Rob came late in the evenings. Initial feelings are that it's going to be a great product. The thing the really impressed me is not the product (yet), but the customer service I received from Rob. He spent a large amount of time this weekend trying to solve my problems when he didn't need to. All he wants in return is feedback on the product. It makes you feel kind of special. Certainly it makes me want to use the product. Thanks Rob. 

Whilst browsing Will's Blog: he's found a cool little utility called Microsoft TimeZone. It's a small .NET application that sits in your system tray, when you click it shows the time in up to 5 locations. Useful for knowing how to greet your Messenger buddies.

What it really interesting though is the download. It seems Microsoft would like you validate your copy of Windows before you download (this is a picture so don't try and click):

The link takes you to a page describing the benefits of genuine Microsoft software. I love the fluffy reasons they give: "greater reliability, faster access to support and overall richer experience". What they really mean is "we don't like people who steal our software, we are going to make it hard for them". As a software developer, it's a sentiment I agree with.

[Edit: there is more detail at http://www.microsoftmonitor.com/archives/003782.html]

I was just looking to get into music downloads and guess what Scoble says. Is he psychic?

Need some fun rave-style music to get your productivity up? Mix Of the Week provides it.

(via Scobleizer: Microsoft Geek Blogger)

Sometimes, when you have to get a lot done in a ridiculously short time, you need a different approach. As a case in point, we need to replace all the remaining ASP code in our product with ASP.NET before we add some essential new functionality. If we don't we will be stuck with the old code forever. This new functionality has to be delivered in a matter of weeks. It could be implemented in classic ASP but it will be much easier and faster using .NET.

What is called for is a few days of pure implementation. No "discussion", no "difference of opinion", just code. It's risky - probably only a 50% chance of success but if it works then we could save days in the immediate future and additional weeks down the line.

There is a way this could work; by modelling the team on an operating theatre. In this setup, there is one person who does the bulk of the work backed by a second to provide help and support. These two make the core pair - everything goes through them on the way into the product. The rest of the team are assigned packets of work by the core pair on an as needed basis. When the packets are complete they are given back to the core pair to stitch into the product. Effectively, one feature at a time is worked on by the whole team.

The main benefit to this style of team is the minimal communication needed, resulting in a higher code to comms ratio. The packets of work are usually so small that they can be described in a couple of sentences. If the result is not quite right then the core pair make whatever changes are required saving the time usually spent explaining additional work to the developer.

There are two key points to note before you embark on a development style such as this. Firstly, the core pair has to have a very strong shared vision of what the result should be. If not then you won't be on a straight line to goal and too much rework will kill the efficiency of the method. Secondly, it can be a bit ego bruising to the non-core developers. They are told exactly what to produce, they have no real opportunity for free thought and the code they return may be modified or even not used. Nearly everyone can put their needs and feelings on hold for a week (even developers) but I wouldn't push it beyond that. This is only for tiger-team style development.