There are a lot of new features coming in the next release of Visual Studio and related products. They are easily discoverable but I thought it would be helpful to bring as many videos and screen casts as I could find into a single list for easy consumption.

A word of warning though, I can’t be held responsible for the feelings brought on by the realisation that you can’t use any of this stuff in a supported way right now. Just try to relax and think how much better, faster and easier your job will be when it is finally released.

General

Microsoft Visual Studio Team System: A Lap Around VSTS 2010

In the spirit of an agile sprint, see how to use the next version of Visual Studio Team System to manage user stories and re-factor existing architecture. Learn how to diagnose real production problems, debug in-production virtual labs, capture test data to eliminate the no-repro bugs, transparently plan, monitor, and adapt software projects.

Team Foundation Server 2010: Cool New Features

Dive deep into the next version of Team Foundation Server (TFS), and learn how TFS has factored its learning's about usability, industrial scale, geographic distribution, manageability, and development process into the next version of the product. See a demonstration of build automation, policy checks, parallel development, new project planning and tracking features, such as agile planning, end to end traceability, reporting, and dashboards, administration and ops --all designed to improve transparency and velocity for teams from size 5 through 50,000.

A first look at Visual Studio Team System Web Access 2010

Visual Studio Team System Web Access has become an increasingly popular way for people to access Team Foundation Server. In this interview we meet Hakan Eskici who demonstrates some of the upcoming features his team is working on for Visual Studio Team System Web Access 2010.

Project Management

Agile Planning Templates in Visual Studio Team System 2010

Stephanie Saad shows us a quick demonstration of how Visual Studio Team System 2010 will enable teams to be more agile. In this demonstration she shows the new Agile planning worksheet for Excel which can be used to easily balance resources, manage your backlog, and generate ad hoc reports.

Enterprise Project Management with Visual Studio Team System 2010

Ameya Bhatawdekar, a program manager for Team Foundation Server, took a few minutes to take us through the end-to-end storyboards for how Team Foundation Server 2010 will integrate with Microsoft Project Server to enable true enterprise-wide collaboration. Note that this is not a demo of working software (yet), but it's the next best thing - a detailed storyboard walkthrough of mocked-up screenshots.

Requirements

Requirements Management and Traceability with Visual Studio Team System 2010

How can you ensure that a requirement has been sufficiently tested? How do you track the work that goes into a specific feature? How much work is left to do before a feature is completed, and how does that feature relate to bigger scenarios or user stories?
Siddharth Bhatia, a senior group program manager for Visual Studio Team System, takes us through an end-to-end example of how Visual Studio Team System 2010 will help an organization manage their requirements throughout the lifecycle of a software project.

Architecture

Architecture without Big Design Up Front

Microsoft Visual Studio Team System (VSTS), code-name "Rosario" Architecture Edition, introduces new UML designers, use cases, activity diagrams, sequence diagrams that can visualize existing code, layering to enforce dependency rules, and physical designers to visualize, analyze, and refactor your software. See how VSTS extends UML logical views into physical views of your code. Learn how to create relationships from these views to work items and project metrics, how to extend these designers, and how to programmatically transform models into patterns for other domains and disciplines.

"Bottom-up" Design with Visual Studio Team System 2010 Architect

Suhail Dutta, a program manager on the Visual Studio Team System Architect team, gives us a demonstration of the "bottom-up" design approach which will be possible with the Visual Studio Team System 2010 Architect product.
With "bottom-up" design, you can quickly reverse engineer an existing code base to construct models and examine relationships between pieces of code. Suhail also shows off some of the new UML designers coming in Visual Studio Team System 2010.

"Top-down" design with Visual Studio Team System 2010

"Top-down" design is an approach that the Visual Studio Architect team is enabling with their upcoming release, Visual Studio Team System 2010. In this "humanized screencast" we asked Mark Groves, senior program manager, to show us a demonstration of the new UML designers the team is building and how this can be applied to a "top-down" approach when building software.

Development

Agile Development with Microsoft Visual Studio

Visual Studio has built-in tool support for agile practices such as Scrum, XP, and others. The next version adds practices like test-driven development, continuous integration, and single product backlog. See how these can be applied at scale and across geographies.

Web Development and Deployment with Visual Studio 2010

Welcome back to another Visual Studio 2010 and .NET Framework 4.0 Week video. In this latest installment, we catch up with Vishal Joshi, Senior Program Manager on the Web Development Tools team.  In this video, Vishal shows us what is being done in Visual Studio 2010 around web development and deployment. Covered are topics like JQuery support, HTML code snippets, better Intellisense, and a whole slew of new features around web deployment.

An early look at Team Foundation Build 2010 with Jim Lamb

In addition to being one of the nicest guys I know, Jim Lamb also knows a thing or two about build automation. Jim is the program manager responsible for the Team Build capability of Team Foundation Server. Team Build was one of the biggest areas of improvement for Team Foundation Server 2008, but that hasn't stopped the team from doing even more landmark improvments in Team Foundation Server 2010.
Jim shows off how Team Build 2010 will take advantage of Windows Workflow, build agent pooling, distributed asynchronized builds, and two new types of build called "buddy builds" and gated check-ins.

Branching and Merging Visualization with Team Foundation Server 2010

Is your source control branching out of control? How much time have you wasted trying to discover which branches your code changes have been merged into? What are the code-level differences between your main, test, and production branches? Branch visualizations to the rescue!

Test

New Web Test Debugging Features in Visual Studio Team System 2010

In this video Ed Glas shows off new Web test debugging features in Visual Studio Team System 2010, including Search in playback, view recording log, jump to Web test, and Add Extraction Rule from Playback.

10-4 Episode 18: Functional UI Testing

In this episode of 10-4 we look at a new type of test coming in Visual Studio Team System 2010 known as the coded UI test. Coded UI tests can be created to automatically navigate through your application's UI, which in turn can be used to verify that the paths your users might take through your application are working properly. You can also add validation logic along the way to verify the properties of objects within the UI. Much like unit tests can quickly surface regressions on a method or function level, coded UI tests can bring the same level of rapid automated testing capabilities to the UI layer.

UI Automation Testing with Visual Studio 2010

Just playing with some of the new Testing features in Visual Studio 2010 and thought people might be interested in the new interface for Camano and a new feature for CodedUI Tests...pulling the automations strips directly out of TFS!

Lab Management coming to Visual Studio Team System 2010

Today at TechEd Barcelona, Jason Zander announced that Visual Studio Team System 2010 will feature a brand new Lab Management capability to help organizations raise the bar on software quality. Lab Management will integrate with the rest of the Visual Studio to help testers more easily test a variety of configurations in a virtual lab environment, and help developers more easily repro bugs by delivering snapshots of those virtualized environments after bugs are discovered. I had a chance to sit down with Ram Cherala and Vinod Malhotra to get an in-depth look at how this will work.

Microsoft Visual Studio Team System: Leveraging Virtualization to Improve Code Quality with Team Lab

Would you like to test fixes in a production-like environment before checking them in to source control? The Visual Studio Team System (code name "Rosario") release of Team Lab improves productivity and quality while reducing the cost of building and testing world class products. Learn how Team Lab provides a fast and easy way to create a test environment and tear it down, target specific test environments, and take snapshots of an environment for easy deployment.

Microsoft Visual Studio Team System: Software Diagnostics and Quality for Services

In this session we present processes and tools from the upcoming Visual Studio Team System code name "Rosario" release and Microsoft Research and show how we deliver on quality, scalability, and experience goals for the new class of applications that demand rich UI, service consumption, and frequent release.

Manual Testing with Visual Studio Team System 2010

Naysawn Naderi takes us through manual testing in Visual Studio Team System 2010. Naysawn shows off how the manual testing capabilities allow not only for better authoring and execution of manual tests, but can also be a tool to help automate portions of manual tests as well. Finally, Naysawn shows how to turn a manual test into a coded test which can then be fully automated.

Historical Debugger and Test Impact Analysis in Visual Studio Team System 2010

Are you tired of constantly setting breakpoints to hone in on a pesky bug? How would you like to be able to step "back in time" through your debugger? The Historical Debugger in Visual Studio Team System 2010 promises to revolutionize your debugging experience. Habib Heydarian takes us through a demonstration of just a few of its capabilities.
But wait... there's more! Habib also shows us the new Test Impact Analysis feature his team is working on. With Test Impact Analysis it's possible to determine which of your tests will be... well... impacted by the code changes you're making! Not only does this mean that your unit test suite can run more quickly, but it can also lead to better testing and fewer bugs in software projects.

Automated User Interface (UI) Testing with Microsoft Visual Studio Team System 2010

Come hear about the new Visual Studio Team System 2010 tools and APIs for helping test a broad range of UIs that can consist of Winforms, AJAX, and Windows Presentation Foundation. See how to use Team System 2010 to ensure UI and application quality.

Time to clean up all the shortcuts to interesting web pages sitting around on my desktop... In no particular order:

• Remember Waitr? What about a .NET version instead - WaitN.
• A long list of sample applications for SharePoint 2007.
• Rules to better SQL Reporting Services 2005.
• Get More Out of SQL Server Reporting Services Charts.
• Analysis Services Stored Procedure Project - this contains some .NET external procedures for SS/AS, for example RegExFilter and AsymmetricSet.
• Best SQL Server 2005 MDX Tips and Tricks - Part 1 - these guys really know their stuff.
• The 18 Mistakes That Kill Startups.
• Seventeen Tips for Iteration Planning.

For some reason when I’m developing something new I always end up changing my design twice. Note, I’m not talking about architecture here. Architecture is a higher level concept and as such isn’t killed by implementation detail the way a design is. I think there is a reason for this multi-version development though.

The first design is basically a prototype exploring possibilities. At this point I’m not sure what the best solution is or even what techniques might be best to employ. It only just does the job and is probably not very elegant or efficient. Not something to be proud of.

The second is usually a great design but, more often than not, flawed with a super hero style weakness. It will be elegant, efficient and cover every requirement imagined. The only problem – it will never be finished. This second iteration is usually complex, over designed and would take an eternity to implement.

After a good dose of reality, the third version takes shape. It’s much more practical, easier to maintain and solves only the requirements that are actually needed. These three designs are usually quite different. Not what the XP crowd would call iterative implementations but the end result is similar.

I think it’s important not to get too attached to any one way of doing things. I see some who start coding and stick with their first design to the bitter end no matter what. People often complain that a v1 product is OK for early adopters but not general consumption. Iterative design like this enables that sought after v3 product in your first release. Just don’t take three times as long to implement it…

OK, I’m a little embarrassed to admit but I’ve been suffering from coder’s block this week. It’s a state similar to writer’s block which is defined as “a usually temporary psychological inability to begin or continue work on a piece of writing”.

I think probably everyone suffers it from time to time and, although I haven’t had a case for a number of years, this has come at a most inopportune moment because we are on a very tight schedule with our current release.

I guess it’s a little like depression in that you can’t just mentally “fix it”, you need to work through the cause. In this case I don’t think it’s an inability to write code, it’s more a case of too many possible solutions to the problem in question. They are all good but none are perfect. In particular one of the requirements is to allow additional code generation (note – not just an add-in, this is adding to the system) post release by our professional services engineers. This is hard for me because my brain prefers to work spatially – I need to see the design animated in my head before I code it up; not something that’s possible if an unknown chunk of code if going to be added by someone at a later date. Talking with other developers didn’t help because all that did is give me more good solutions to consider.

The other problem is that there are a number of very intricate details that have to be thought about or the implementation won’t meet the requirements. Completely overwhelming if you look at them together so on Friday I decided to take a leaf out of the extreme programming book – baby steps. I started by ignoring the mass of requirements and implementing a really small section. By lunchtime I was back in the flow, I managed to check-in something yesterday evening and things are looking to be back on track.

So if you are suffering similar then I can offer the following advice:

• Take a break and do something completely different like go for a walk, however doing this too often is just procrastination
• Try and work out what is causing the block and fix those issues one at a time
• Take small steps to get something (anything) working
• If all else fails, see if you can swap your feature with another developer

This one can be expanded to selling anyone on an idea:

• A must read article on “How to sell your boss (on an idea)”

The usual set of MSDN articles:

• Report-enable Your Web Apps with Microsoft Reporting Services
• Customizing MSI Installation (with Visual Studio installer projects)
• VB-Helper: Stick to the Script (script integration with .NET)
• Internal SQL Server Diagnostics Tools, Part 1: PSSDiag

Some notable downloads:

• Do-It-Yourself Script Center Kit
• Microsoft® Windows AntiSpyware (Beta)

Finally, a couple of excellent articles by Michele Leroux Bustamante (dasblonde)

• Sandboxing Components for Impersonation
• Designing Role-Based Security Models for .NET

So I haven't had time to blog much. There are, however, a number of links on my desktop that I've collected and meant to take a look at. So I can tidy up I'll list them here instead.

• The Fallacy of Cheap Programmers
• Skinning Gmail with a Custom Stylesheet via Nick Bradbury
• Mount St. Helens Volcano Cam
• Moving Past Fear via Heather
• Creating multilingual web sites
• The Daily Database Build
• Microsoft ASP.NET ValidatePath Module (to fix this)
• Hacker Handle Generator via Gnome-Girl (James Snape = Zen Dead, I might even use it)
• NASA's WorldWind (free download) via Steve Makofsky
• UI Patterns and Techniques via Duncan Mackenzie
• Cooking for Engineers via Raymond Chen

Plus some useful articles on MSDN:

• CRUD, Only When You Can Afford It
• Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components
• Windows Forms Development Series of Webcasts

(*) The title is based on a quote by Jesse from the Fast Show. Spoken in a West Country accent.

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.

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.

They only seem to care because we, as software developers, make them play the requirements game. In reality, the only thing that that matters is how the final product matches up to their expectations. The big problem is that you can't capture them in a document to use as the blueprint for development. There are some things you can to ensure your customer is happy with the end result:

1. Write a short "Vision" document describing the key features to get everyone on the same page early on
2. Program by feature to produce functionality early, don't spend too much time on infrastructure
3. When you've completed a feature, show it to the customer and get feedback
4. Allow the customer to change their minds

These points will only work when both you and the customer share the project risk; either with fixed rates/variable time or fixed time/variable functionality.

If it's a fixed price/fixed functionality contract then you'd better start writing those requirements...

I have a meeting tomorrow to discuss a number of deployments we have in the next couple of weeks. One thing to note is that all installations come with their own set of problems and I don't always have the answers. However, preparation is key; as they say - "pathetic preparation makes for a piss poor presentation".

One thing I'm going to try is a bit of brainstorming. I'm going to draw up each installation on a white-board and we'll list up anything that could possibly go wrong. From that we should be able to plan for nearly every eventuality. Hopefully it won't be a too depressing experience .

The main stay of my deployment plans is practise. If you have done it in the office without a customer breathing down your neck then the real thing is usually much easier. We try and get hold of a backup from the customer as they usually have datasets containing unforeseen combinations of data (especially as the source database doesn't have any constraints - shame on you Cisco!).

The last thing that commonly trips us up is firewalls - most of our customers are in retail or banking so security is sometimes taken to the extreme. It would be costly for us to reproduce their firewall configuration (one customer has DMZ's around each server), so a quick tip is to use personal firewalls such as ZoneAlarm to lock down your test servers similar to a DMZ deployment.

I've just started reading "Agile Project Management" by Jim Highsmith and it's looking very promising. Whilst reading chapter one the point slapped me like the Tango Man - it's the way in which agile projects are different to others.

Traditional project are all about deciding what you are going to build and then carrying out your plan whereas with agile projects you have a plan but it's about how, not what, you build. In fact the key point made by Jim is that agile projects are all about experimentation and adaption.

He cites a comparison with the pharmaceutical industry which makes things very clear. A few years ago they used to sit down and design molecules for a specific task whereas now they synthesise thousands of molecules at a time and use automated testing to screen for desired properties. The results are fed into a database which the scientists use to make their next steps. This rapid experimentation enables them to generate new drugs much faster even though they don't know the end result until it presents itself.

Consider this in the context of software development. Rapid cycles of experimentation with unit tests to screen the results and ensure forward motion. These two concepts enable a project to progress in a more efficient way than if a solution were "designed".

man·age·ment

The act, manner, or practice of handling, supervision, or control.

lead·er·ship

Capacity or ability to lead, give guidance and direction.

There is a big difference between the two.

We hold these every morning at 10:30am as it's a time when everyone can get into the office. Three questions are asked of each developer:

1. What did you complete since the last meeting?
2. What blocked you since the last meeting?
3. What do you intend to complete before the next meeting?

The answers to these three questions provide a snappy status update for the entire team. In particular, the second question is a direct request me me to do something.

To keep the meetings short there is supposed to be no additional discussion beyond the three questions. If needed then it should be scheduled directly after the meeting. However our meetings have recently begun to drag on as I found the "after meeting" gatherings weren't happening and I let the discussion happen in-line for fear of it never happening (a self fulfilling prophesy?).

The side affect of this is to subject everyone to a level of detail that may not be relevant to them, wasting time and boring them. So today I've asked everyone to answer their questions in 2 minutes. The benefit of a short meeting is obvious but in addition it gives people practise at concise communication.

Hopefully this should work, but if not then I'll resort to a trick I used at Sony - a two minute egg timer. Once the time runs out you have to shut up. If you have more to say then you have to e-mail everyone.

A note for self though - I must ensure the post meetings happen.

In an earlier post I promised to explain why I didn't remove a block for one of the devs. Well here goes...

The block in question was a customer who needed support for a new version of our product they were evaluating. This type of job should really be handled by either the support guys or our professional services people. However, the version of the product being evaluated has only just rolled off the build machine and they haven't yet had the chance to get up to speed with it.

Obviously, customers are the life-blood of any company and therefore their needs must be met by any method available. We are a small company (approximately 30 employees) so roles are not so well defined as "developer" or "support" - we have to muck in and help out with whatever may be required. If that means investing time in a customer with the potential to produce revenue then so be it.

Given these circumstances, I think its justified to divert development resource in pursuit of customer needs. One thing to strive for next time though is better training and preparation for the people supporting the product.

"Show and Tell" was a success. There was plenty of cool things to see - especially as one of the developers managed to sneak in some functionality I was unaware of. There was a particularly good demo and talk about an MDX report designer using the Office Pivot table component.

One thing to change for next time will be a stricter time-box on each presentation. The whole thing was three hours, a little to long to concentrate for. So I plan to limit each one to 5 minutes and ensure everyone focuses on the key stuff.

I'm on site with a customer tomorrow so Monday will be sprint planning day.

Tomorrow is "Show and Tell" day. This is our take on the Scrum Sprint Review where the idea is to demonstrate the team's progress and direction to the Chickens. The review is open to anyone who would like to come and see what the engineers have been up to for the last month. The format is fairly loose - as all the developers have laptops they can take turns to plug into a projector and show what they've been up to. Individual presentations are limited to 15 minutes + question time.

The benefits are obvious: engineers get a chance to show off their work and direct feedback from the people who are dependent on their creations; Sales, marketing and management get to review progress and provide input.

There is always a little nervousness on my part because I don't do much speaking - it's up to the individual developers. Their view of the world revolves around code, architecture and designs whereas the chickens think about schedules, customers and revenue. With the two positions, there is some room for difference of opinion but regular reviews keep everyone on the same page.

So roll on the demos...

Its nearly the end of the month and hence end of the current sprint. I was having a discussion with a developer this morning about the amount of work remaining on the list. The developer in question hasn't been able to spend a lot of time on the project this month due to higher priority customer needs and therefore won't be able to complete his agreed functionality.

According to Scrum, we have two seemingly opposing forces:

1. The end of sprint review where the team shows the progress for the sprint
2. The rule that "only potentially shippable code" should be shown

The problem is that his part of the system is the user interface and without it the sprint review will be mostly white-board and some of NUnit tests. Not very exciting and not liable to provoke much discussion. So he asked the question - "Should I just hack it to get something on screen"? I had to think about this for a while because its very tempting to say yes. I could almost justify it by saying that its demo code and will be thrown away.

After, musing for a couple of minutes I said no for the following reasons:

1. Rule (2) above
2. The sprint review is designed to show project progress and demo code is not progress
3. The act of hacking in demo code and pulling it out again tends to add entropy and hence bugs into the system

So a question for a future post should be "Why did I not clear the block (customer needs) for the developer?".