We spent about three hours in the Las Vegas Outlet Centre which is to the south of the city (if my internal compass is working correctly). My reward for being a good boy was a visit to the Frys electrical store which is one of the chains here, and a mecca for all serious geeks as far as I am concerned.

In the evening we went to see Cirque Du Soleil. There are a few different shows playing in Las Vegas at the moment, but we decided to go and see Mystere which is on here at Treasure Island. The show was great, everything that we’ve come to expect from Cirque Du Soleil (we saw Dralion recently in Melbourne when it was on tour there). The highlight for me was the clown who managed to get quite a few laughs from the audience.

Along the way we stopped off in San Bernardino at Papa Tony’s Diner and got some pointers about the road ahead. We missed most of the heavy traffic that came through on Friday so we had a clear run.

Victorville was interesting and we managed to drive around it a few times. When we got into the hotel we realised that I had incorrectly assumed what kind of plugs were used over here (you’d think I’d know by now given I’ve been here several times). Anyway the result was we had to drive around the town a bit to find a place where we could find some adapters.

Ironically for dinner we headed over to the Outback Steakhouse for some good old Aussie cuisine – well not quite, I didn’t really spot anything uniquely Australian on the menu – not a snag in sight.

This morning we set off again to cover the final 294km to Las Vegas. The road between Victorville and Las Vegas is mostly desert with plenty of shrubs. There is some very dramatic scenery especially as you head down into various valley’s and can see the highway heading up the other side.

While in Vegas we are staying in Treasure Island which is one of the casinos here. This was the first time that either of has had been to Las Vegas so we decided to go and gamble a little bit, neither of us are really big gamblers but I wanted to play a hand of Texas Hold’em. We had dinner at the Coffee Shop and played a bit of Keno (first time) and then headed over to The Mirage via a little tram that runs between both venues.

Tomorrow we are planning on doing a bit of shopping at a factory outlet and I’m going to take Shelley to Frys which has to be one my my favourite shops in the US.

The big drama on this trip so far has been that I had a bit of a fall last weekend which resulted in a knee injury (bruised bone, torn ligament, and a dislocated patella). I did it walking the dog when three dogs ran up behind me and tried to occupy the same space as my leg – I came off second best. Anyway, a week later it is feeling much better and the doctor gave us the green light to travel so I’ll spend the next week on crutches then I should be OK walking around.

Anyway – we a flying into LAX then jumping in a hire car and heading off to Las Vegas which is probably where my blog post will be from.

Continuous Integration tools doesn’t necessarily help here as they typically just run unit tests to ensure that the code is functioning at the unit level, not take the application installer (hopefully you have one) and roll it out onto some virgin infrastructure.

The truth is that a lot of teams don’t really consider what their finished product will look. So here are some questions to consider:

• How will you install your application? XCOPY or Windows Installer?
• How will you configure your application? Post installer configuration tool?
• How will you service your application?
• Windows Installer patching or something else?
• Do  you need to uninstall first?
• What about your database schemas?
• Do you do them at installation time?
• Are they in a separate setup package?
• What about servicing for databases?
• Do you create maintenance plans?
• What about repair operations?
• Do you have some kind of health check mechanism?

Setup Packages Are Software Too!

The truth is that the setup package that you use to deliver your software is part of what you are building as well so you need to put as much thought into that as you do the application functionality.

• Which logging framework should we use?
• Which IoC container should we use?
• Which packaging tool should we use?
• Which database deployment tool should we use?
• Which navigation framework should we use?

With all of these there are multiple choices that we could make, but there tend to be a few categories that they fall into:

• The default choice.
• The popular choice.
• The weird choice.

Notice that there is no right or wrong choice in that list, there are just choices. By definition the default and weird choice aren’t as popular as the popular choice, although they probably both have some level of support from someone in the team.

The challenge is – which choice should you make? Well, you really need to evaluate it against a set of criteria:

• Is the choice going to work us now?
• Is the choice going to work for us later?
• …

But I want to step back a little bit and look at the Default Choice again. For example, in the case of database deployments, the default choice for me on the .NET platform is to try to use vsdbcmd.exe. I get a bit of push back about that because people don’t trust what it is doing, but what other choices are there?

• The popular choice: change scripts, manually applied to the database.
• The weird choice: build our own database deployment tool.

I usually here the popular choice coming from DBA’s, and I usually hear the weird choice coming from the software development team members. But both stem from a lack of trust in what Microsoft has developed with DBPro. I get that, I’ve seen some of the issues myself, but overall it does work.

To me, for a .NET development team targeting a SQL server database backend, vsdbcmd.exe is actually the default choice and you need a really good reason not to use it. The popular choice is my second favourite because it is often a reality when you are dealing with customer DBAs, but I don’t think the weird choice (the re-invent the wheel choice) is the way to go because you aren’t going to be able to build a tool powerful enough in the time you have available.

Unfortunately as business comes to rely more and more on technology solutions it starts to become very expensive to have to contiually re-implement the same fuctionality every five years or so simply because the organisation has forgotten how to effectively maintain their existing software assets.

Part of the problem is how we handle code after the system goes live and has achieved its first real period of stability. Typically a project team will be around to support go-live and work out most of the initial quirks with the software but soon enough the organisation has to disband the team and hope that the team has done a good job. More often than not the source code gets zipped up and put on someones shelf, or if you are lucky locked away in a dark corner of an enterprise version control repository.

Eventually that system is going to need a revision and this is when the fun starts. First of all the expert engaged to do the fixing needs to find the software asset. Second they need to resurect a lab environment so they can figure out how the solution works. Third, they need to make the change, and fourth test it. When people think about maintaining software they assume that the third and forth steps can happen without really needing to consider the first and second, unfortunately that just isn’t true.

To do it properly you need a way of transitioning your software development environment to a sustained engineering environment. This is where I think the true value of an ALM solution like Visual Studio 2010 Team Foundation Server and Lab Management comes into play. If you do it correctly when the project team spins down your build environment remains, in fact your test environment remains virtualised and all you have to do is spin it down to preserve compute resources and bring it up every X months to make sure it is still viable.

This is the essence of sustained engineering. It isn’t about support for an application, it is about the scheduled activities that a skilled individual undertakes to make sure that the code base that sits behind that critical corporate information asset is still viable.

Devpods add to our market offerings by giving organisations that don’t have an internal development team, or who need a high performance team to just get in and get the job done. We have already deployed a number of Devpods and I’m happy to report that they are working extremely well.

Methodology and Tools

We use a combination of the Scrum methodology and Microsoft’s latest ALM tooling to keep the projects on track and make sure all stakeholders know what is going on. In fact the presentation that I am giving tomorrow in Canberra actually shows off some of this tooling.

Collateral

Of course – there is a lot more to building a project delivery capability to market than saying we use Scrum and installing a bunch of software. Thought needs to be given to how we promote the concept to potential customers, understanding who our customers really are as well as pulling together some of the other collateral such as standard proposals.

Fortunately most of this is behind us now and we can start to focus on engaging with more customers.

Next Steps

Now that I’ve got the time to sit up and look around I’m starting to see some of the other things that I need to focus on to continue to strengthen the offering. Whilst we are already delivering Devpod projects to customers already we’ve picked up a few good ideas that we’d like to invest in.

Anyway – at least you know what I’ve been up to for the last eight months.

You have about 14 hours left to get your booking in according to the registration page so you had better get cracking if you are interested in coming along.

In the session I provide an overview of what MTLM is and what problem it is trying to solve and move onto looking at some of the core topics, including:

• Planning your testing effort.
• Writing test cases against user requirements.
• Tracking your testing effort across multiple configurations.
• Recording test runs for playback.
• Automating test runs in lab environments using Coded UI tests.
• Understanding when its time to automate testing.
• Tips for getting started with lab management.

During the session I’ll actually be showing a live environment which is actually being used. Unfortunately we haven’t had a chance to upgrade to the Release Candidate that was released today, but I’ll point out any significant differences you are likely to find.

We are currently looking for a junior-to-intermediate level developer who wants to get on the pathway to consultancy to work as the primary developer for internal development projects, supporting existing code bases and creating new application to support our business.

You must already have experience with the .NET platform, preferably .NET 3.5 with a desire to move to 4.0 within the coming months (we already have some 4.0 code bases). This is a Melbourne-based position and you’ll be working from our offices in Docklands working with managers across the business to support their needs.

Longer term this is a great way to move towards being a Senior Developer so if you want to move beyond what your current role can offer you and start working with a large variety of technologies such as SharePoint, CRM, SQL Server and of course the latest development tools from Microsoft then please contact me at mitch.denny@readify.net.

Thanks – please pass this on if you know someone who could fit the bill. I’d imagine this would suit a recent graduate, or someone taking a break from university who already has some development experience.