Planet SCM

It's Friday afternoon, so I hope my readers will indulge me a bit of gloating over three recent moments of personal triumph:

1. Playing the 12^th hole at my regular course, I made a shot from about 80 yards out.  Unfortunately, it was for par.  :-(
   
   
2. This past Saturday I walked the Indianapolis half marathon in a personal record time of 14:57 per mile.
   
   
3. After setting up my new subwoofer, I put in the Return of the King DVD and zoomed ahead to the Minas Tirith battle scenes.  Seconds later, my younger daughter ran upstairs and cried, "Daddy, your movie is shaking the whole house!"

All three of these were moments of great personal satisfaction.  The third one was the only one to result in maniacal laughter.

In the lead-up to the debut of the movie “Transformers,” there was already plenty of Transformers merchandise available. My son, who was 2 ½ years old at the time was instantly entranced. While my wife was strolling him through the bookstore he grabbed a Transformers calendar without her noticing. When she got to the register he then used his charms to convince her to buy it.

The Challenge
This got me to thinking. Wouldn’t it be fun to build my son a car out of Legos that could transform into a robot? After all, how hard could it be? I decided to give it a shot and I set myself the following design goals and constraints:

1. Build a Lego model that has two forms: a sports car and a robot
2. Folks looking at it agree that each form is clearly recognizable as that form
3. On casual inspection, it doesn’t look like it transforms
4. 100% Lego, no other parts, and no glue
5. Easily held in one hand
6. Strong (parts don’t fall off easily during use)
7. Robot form can stand on its own
8. The model can easily transform from one form to the other
9. Model is completely connected and transformation does not require the addition or removal of any parts
10. Fully articulated

Now, a year and several generations of Lego models later, I've finally created a Lego model which meets these deceptively simple goals.

As the project progressed, I wasn’t thinking of it as an exercise in iterative design or a formal project, it was always just something I did for fun in my spare time. I didn’t realize the link to iterative design until I started talking to people about the history of the project.

Transforming Requirements Into Working Software
When working with software, even if you have clear requirements that you have validated with users, it is not always clear how you will implement them. The search for a solution has two possible components: thinking about how to do something and implementing something. When thinking about how to do something, that’s really just fantasizing. Of course, it is fantasizing that is focused on producing something real, and it is more likely to produce something real than fantasizing about winning the lottery, but it is still fantasizing.

Requirements, analysis, specifications, and design are all examples of fantasizing. Yes, it is useful to do it, and you will often hit on solutions or eliminate problems much more quickly and much more economically than creating something real without giving it the same amount of thought, but fantasizing is only an approximation of reality, an interlocking web of educated guesses. Not until you actually attempt to create something real will you find out how all of the individual requirements interact and the real costs and difficulty involved. You don’t always find a clear match between requirements and implementation that is cost-effective to implement. In this case you have four paths forward: implement with the closest match and hope for the best, search for new possibilities, invent new possibilities, or shelve the project.

Transforming Lego Car, Iteration 1
The first attempt to build the transforming Lego car didn’t go very well. I was able to create a reasonable looking car which had lots of interior space for the mechanics needed to transform, but creating the sliding parts and the joints proved to be more difficult than I had imagined. I had lots of different hinges, flat parts, special joints, and Technic parts, but all of the possibilities I came up with were either too big, too fragile, too loose, or didn’t support articulation well enough. I was stumped. After a quick trip to the nearby Lego store to see if there was something I had missed, I reluctantly decided to shelve the project.

From a requirements perspective, I had satisfied requirements 2-6, which is half of the requirements. Of course, it was easy to satisfy "doesn't look like it transforms" because it didn't transform at all. :-) From an Agile perspective, the car was fully functional as a car in its own right, and I had discovered lots of valuable information that would help with later iterations of the car.

Little did I know that a hidden bias had kept me from seeing what was right in front of me. It wasn't until a couple of months later that serendipity broke through that bias and brought together the necessary ingredients for the first transforming version of the car.

Next: Part II (of 2)

In Part I, I talked about how the design of a Lego car that can transform into a robot illustrates the process of iterative design. At the beginning of the project, I had the exact requirements and they didn't change at all from the start of the project to the end. However, just having the right requirements did not mean that I could immediately design something that would meet the requirements. At the end of Part I, I had a Lego car that met many of the basic requirements, but still didn't transform. I was stuck because I didn't have the technology that would meet the rest of the requirements.

Part of iterative design is keeping your eyes open, always looking for ways to intelligently expand the solution space. If the information you need is not already at hand, trying variations of things you already know may not lead to a good solution.

Thinking Outside The Box
I had always eschewed the Bionicle Legos as “not really Lego,” so I hadn't originally considerd those. But then two things happened that breathed new life into my Lego project. My son’s third birthday was coming up, and my wife suggested that we make it a Lego birthday. I was responsible for filling the gift boxes for the guests, and I decided to start by visiting the Lego store to see what they might have.

The Lego store had a wide variety of gifts for $5 or less including Duplo dinosaurs, a pony and princess set, knights on horses, and most importantly (for the project) small Bionicle sets. I had never bought a Bionicle set before, so I had never noticed that many of them had articulated joints. The joints were ball-and-socket parts which were small and had enough friction to make them poseable. They were perfect for the project.

There is another kind of Lego set called Exo-Force which has a completely different technology for doing articulated joints and also has a part which when combined with a Bionicle part provides a third technology for articulated joints.

Creating limbs which can fully fold up is a difficult proposition at best. But, I managed to create a couple of variations that allowed me to create the next version of the project. It didn’t really meet the goals of looking like a sports car or hiding the fact that there was more to it than met the eye. It was quite boxy, had odd proportions, and some of the joints were exposed. It was also fairly fragile. But, it could transform!

Sometimes Flexibility is Constraining
Sometimes software that is too generic or two flexible creates another set of problems such as taking too many resources or being too difficult to configure for the task at hand. The knee and elbow joints of the robot form had the same problem. Because they were fully articulated they were just too darn big and difficult to hide. I knew that these joints didn’t need to have the same degrees of freedom as the shoulder, hip, and ankle joints, but had not previously been able to create a hinge that could fold flat and have the full range of motion required. I repeated the exercise of determining all of the available hinge options and found a couple of new ones. The most promising one was a dual Technic hinge which was perfect for the knees.



For the arms, this hinge was too large. But then I realized that less resistance was required for the arms and a single hinge would do. Perfect! Now I had the robot skeleton, I just needed the car exterior.

Inspired by Elegant Design
Many months later, when looking for a new Lego set for my son, I saw a new car set (#4939) that was perfect for the project. I’m not an artist by any means, so one of the challenges has been finding Lego car designs to emulate. Previously they had always been either too big or too small. At one point I had been very excited about the Ferrari that comes with both red and yellow exterior pieces, but it was double the size I needed. Set #4939 seemed to be the perfect size. It didn’t hurt that it was very cool looking and reasonably priced. I had the feeling that this was it, I was finally going to achieve the goal.

Using set #4939 as inspiration, I was able to layer a car exterior onto the robot skeleton without too much trouble. As a bonus, the head, which had previously never really worked out well, was just there. I was within reach of the goal. But still one problem remained. I couldn’t cover the shoulder and hip joints without preventing transforming. I needed something that would allow the top and bottom parts to slide out and then lock in place. I had created parts that slid from place to place before for other Lego projects, but never something that could also lock in place.

Sliding Into Home
After trying many variations using small hinges to act as the locks, I had something that worked, but it was just too big. It was also very clumsy. Luckily, I was in denial. I forged ahead anyway. I wasn’t sure what to do about it being clumsy, but I was determined to create more room in the model. The most obvious step was to do what they do to create stretch limousines: take a regular limo and stretch it out. I made the whole model a bit longer, wider, and taller while keeping the same overall proportions. I also removed all unnecessary internal parts or replaced them with parts that would still do the job but took up less space.

It wasn’t enough, and I couldn’t stay in denial about the sliding part being clumsy forever. But while I was stretching things out I observed that some of the technic parts would slide around a little bit when I exerted too much pressure on them. Of course, the part that would give depended on the amount of friction. Whichever had less friction was what moved and the other one did not. From that came the solution: two bricks together to anchor the axle, and one brick that moved freely but with enough friction that it would stay wherever it was slid to.


The slider was the last major challenge. Once I had this part, it was just a matter of trial-and-error shifting things around until it all worked. There are two sliders; one for the lower body, and one for the upper body, the following picture shows the car with the upper and lower body pulled out as the first steps of transforming.



After the car has been extended, the legs are unfolded.



Lastly, the arms are extended. The head is also fully articulated.



There is still room for improvement, but at this point I think it is more a matter of aesthetics than mechanical design. I’m happy with the current design and hope that perhaps a Lego fan with more art skills than I will take the design to the next step. My other hope is that perhaps the amazing folks at Lego will start producing transforming Lego sets. And of course, if they were Transformer branded, that would be a wonderful (but not necessary) bonus.

I’m still working out the best way to make the plans available. Most of the car parts and design will be available shortly via the Lego Factory Store. For those parts, the Lego Designer will automatically create building plans. I’ll update this page as soon as I can with more information on building the model.

Motivation, skill, and experience all play important roles in the design process, but they are no guarantee that you are going to be able to design, let alone build what you have set out to do. It almost always requires trial-and-error, serendipity, creative inspiration, research, and an open mind.

The floor
I should say that Sun did a great job organizing the floor. Or, may be it was just the strategic location we picked up. At any rate we liked the format.

Traffic
For us the booth traffic literally took off. There were times when I was talking to four people simultaneously.



On goodies
We brought cool electronic clocks (challenging to set up, though :) After trying to just lay the goodies out we quickly found out that ~50 of those were going in about four minutes. So, it's a great way to fill Java crowd's swag bags, but it is totally useless from the company's point of view. Don't do it. After seeing this not work we were distributing the clocks mostly to the guys and gals we talked to. It seemed to work better.

Running to Caltrain
The Pavilion was open until 8:00PM. After having a few drinks we ended up running to the SF Caltrain station to catch the 8:33 train. It's a 10 minutes trail with a few traffic lights. A good exercise it was, it didn't feel that good given the wine. I should resume going to the gym, clearly.

To add to the already stellar list of participants for our event I confirmed today that Dale Christian, CIO at Avanade will participate in our CIO Panel Session, and Alan Shalloway of Net Objectives will join our Think Tank / Open Space sessions as a facilitator. Alan will either assist Mike Griffiths on Agile Program Management or Corey Ladas on Kanban. In the event of the latter, I'll be assisting Mike with the program management topic. Technorati tag: Agile, APLN, Lean, Seattle, Edgewater+Hotel, Avanade, Dale+Christian, Netobjectives, Alan+Shalloway

I made a failed attempt to see if we would be willing to make the next version of Team Foundation Server only supported on Windows Server 2008.  Since we'd like to have native IIS7 support in our setup (not require the IIS6 compat like we do in TFS 2008), we're looking at maintaining 2 different code paths, the 2k3/IIS6 method (already coded and tested, thankfully) and the new IIS7 code.

There ended up being a whole slew of benefits to being Longhorn-only (much smaller test matrix, ability to take dependencies on some IIS7 features, powershell in the OS, etc), but it's not going to happen, at least not for this release. 

This means our job is a bit tougher, but for all of you playing along at home, be happy knowing that (at least as things stand now) we won't be forcing an OS upgrade with our next version of TFS :)

I guess it's been my fastest booth set up ever. Setting up the booth for Cacheonix took about 15 minutes from entering the Pavilion to saying goodbye to the security at the entrance and driving back home.

We decided to take simplicity to the extreme and go only with a table, a projector and a screen:



This turned out to be a great choice. We set up a roller in PowerPoint to show eight variants of the display panel in a 10 min cycle. A quick run demonstrated that two images were totally off in the actual lighting environment of the floor. The rest of images were perfect. The set up gave us a crisp, bright and effective display. Bye-bye expensive roll-ups. See how our both stands out compared to the rest:



One thing I would do differently. The environment definitely allowed for a better resolution image. Instead of buying a $499 800x600 Dell 1201MP projector I would get a bit more expensive $599 1024x768 Dell 1409X.

We have opened up the registration for the APLN Leadership Summit in Seattle on July 17-18.

Register now and get the early bird special price of $300.

We have a fantastic program lined up and a uniquely collaborative
conference format.

Key note speeches from

Lisa Haneberg,
author of several books including "High Impact Middle Management",
"Focus Like a Laser Beam" and "Two Weeks to a Breakthrough",

and John Yuzdepski,
Chief Marketing Officer at TestQuest, former VP & GM at Openwave and
prior to that VP & GM of Sprintpcs.com

a CIO panel - featuring leaders from firms around Seattle,
participants to be confirmed

Think Tank / Open Space Sessions led by recognized leaders in the
agile field, including...

Luke Hohmann, Collaboration Games
David Anderson & Corey Ladas, Kanban
Brent Barton & Lance Young (of Solutions IQ), Scrum
Mitch Lacey & Julie Chickering, Getting Started with Agile
Bruce Eckfeldt & Jim Benson, Writing Agile Contracts
Mike Griffiths, Agile Program Management
Chris Matts & Olav Maassen, Real Option Theory
Arlen Bankston & Jeff Patton, Agile User Experience

On Day 1 each Think Tank facilitator will lead an open space group to
develop new material, thinking and ideas. Participants are free to
choose a single session or wonder freely from session to session
learning and contributing to each.

On Day 2 each session facilitator will present a 20-30 summary of the
findings from the previous day. The output from all 8 sessions will be
made available to participants.

Please come and join us. Enjoy the beautiful venue. Enjoy the Seattle
summer weather. Enjoy mixing and networking with leaders in the agile
and board members of the APLN.

It's a mini-Agile Conference in the Northwest.

Enjoy the great food at the luxury Edgewater Hotel. Join us for the
cocktail reception in the evening of the 17th. Technorati tag: Agile, APLN, Lean, Seattle, Edgewater+Hotel, Luke+Hohmann, Jeff+Patton, David=Anderson, Lisa+Haneberg

I’m very proud to announce the first release of smart branch support in Plastic. The release is still not official (so don’t use it for production before contacting us) and it can be directly downloaded here, no registration needed.



What are smart branches exactly? They’re the evolution of Plastic basic branching functionality answering some common users’ demands: they can remember their starting points so that when you switch back to a branch you don’t have to remember it yourself. While this is very good for a number of well-known branching patterns, it will really help our branch per task practitioners when they have to recover old branches.

A smart branch is, conceptually, very close to a stream, but we preferred to stick to the more traditional name of branch instead.

With smart branches Plastic remembers which one is the starting point of a branch at any given point in time. The branch properties dialog (also new in the BL101 release) will show you which one is the current starting point of the branch and will also let you modify it creating a new one (which is very helpful during rebase operations, for instance).

The new properties dialog also lets users modify the branch name and specially its comments, which was something customers were asking for since 2.0 was released.



Changesets are also given more visibility with the new release: they’ve been present in Plastic since day one, but now branches cannot just be created “from a label or baseline” but also from a given changeset, which eases maintenance.
Plastic branch inheritance mechanism is flexible enough to define many different branching strategies and now it can be easily tuned (easier than before) with the usage of smart branches.

A smart branch is just a regular Plastic branch with a link to a starting point. A starting point being:

another branch (in which case it will inherit from the LAST on this branch, implementing dynamically updated inheritance)

a given changeset on a branch (which specifies fixed inheritance from a well defined starting point)

a label (which is the regular case normally used as best practice for branching).

A new changeset is created after a new branch base is set so that users can easily find a checkpoint to be used later on, if needed, to recover this specific configuration.



If you look at the figure above you’ll see that if a developer chooses to go to changeset 99 the branch /main/task001 will use label00 as basis, but label01 if cset 100 is selected.

Changes are also introduced in the selector definition so that now rules like the following will be allowed:

rep “codicetest”
   path “/”
       smartbranch “/main/task001”

And all the required branch inheritance details will be set.

The release BL101 makes all this new functionality available from the GUI and our next release will also introduce support for smart branches from the Branch Explorer.

We expect smart branches to make Plastic branching easier to use for both new and existing users and also introduce more advanced branching scenarios when needed.

Enjoy!

By default local variables in IntelliJ are not colored in any way. As a result, the local variables are blended with the rest of the code and you have to make a little but present mental effort to identify them when reading the code.

The good news is that IntelliJ allows setting the color of local variables. Here is the snipped of the configuration screen:

The challenge is to come up with the coloring that would look natural and go with the rest of the coloring scheme. After trying to come up with a color that would fit into the already busy scheme, I have finalized on the "black bold" for local variables. It is not very intrusive and you still can spot the local variables easily:

Well it looks like TriFork and Accelinnova have struggled to fill the room in San Francisco for Monday's Leadership Summit event.

If you'd like to meet me in person and ask me anything about Agile Management, Kanban, MSF CMMI, FDD, or what we're doing with Modus Co-operandi, then come listen to me present on Kanban at the JW Marriott in downtown San Fran on Monday. Sign up now using code 'd400' to get a $400 discount. Technorati tag: David+Anderson, Software+Engineering, Kanban, Lean

 

I get what it's trying to say, but I'm at a loss as to what the Yes and No buttons will do here.  I'm not sure this warrants WTF, but still.

Actually, perhaps I'm wrong - Chris thinks it warrants it :)

James Manning?? [1:25 PM]:
  ---------------------------
Windows Server Backup
---------------------------
The selected volume is also included in the list of items to back up.  Exclude this volume from list of volumes to back up or add another disk and retry.
---------------------------
Yes   No  
---------------------------
??Chris Rathjen?? [1:25 PM]:
  wtf

Continuing the previous discussion on software product-lines ...

Central to the notion of product-lines and product-families are tracking and managing three different kinds of software assets:

• common/core assets that are shared by all the products in the product-line
• shared assets that are common to some products but not others, and ...
  
• product-specific assets (or custom-components) that are specific to a single product in the product-line.

Architecture for such product-lines is all about managing commonality and variability, and easing their evolution to achieve a diverse family of products to achieve economies of scale from reusing common assets. Change/Configuration Management for SPLs is a very challenging problem. And variability management techniques often come down to a matter of binding-times. There are also more advanced strategies (some involving mathematical models).

A few resources on the subject of Commonality and Variability are as follows:

• A good (albeit old) article on Variability Management in Software Product Lines has a nice overview of some basic variability enabling techniques and the use of binding time
• A dissertations on Variation Mechanisms and Multi-view Architecting in Platform-based Product Family Development
• Expressing Product Diversification -- Categorizing And Classifying Variability In Software Product Family Engineering
• Coplien, Weiss and Hoffman wrote a nice overview article on Commonality and Variability in Software Engineering
  
• Alan Shalloway has an excellent introductory article on Commonality and Variability Analysis in conjunction with Design Patterns.
  

In July 2006 I presented at the Dr Dobbs' Architecture & Design World conference about SCM Patterns for Agile Architectures, which included a section on managing variations. I summarized that portion of the presentation as follows:

Use Late-Binding instead of Branching:
• Build/Package Options
• Feature Configuration/Selection
• Business Rules

Think about which of the following needs to "vary" and what needs to stay the same:
• Interface vs. Implementation vs. Integration
• Container vs. Content vs. Context

Commonality & Variability analysis helps identify the core dimensions of variation for your project

Use a combination of strategies based on the different types of needed variation and the "dimension" in which each one operates

The folks at DDJ have just interviewed me about SCM Trends.
I tried to give my own view about the future of SCM and even talked about how threading and concurrency (which I've to admit is one of my favourite topics since long, long ago I first read Ben Ari's book, now there's a new edition available and also the superb Jeffrey Richter's book which is also renewed this year) have an impact in the version control field, or even better how I believe SCM can help there.
I've also focused on why C# was an important decision in the early Plastic development, and more specifically why Mono was actually the key which really opened the C# door for us!

The stream of new stuff coming out for VS/VSTS/TFS 2008 continues! - see my recent post on an update to the TFS Power Tools.  It is time for me to tell you about what is coming in TFS 2008 SP1.  The release of the Beta is very close (as always, don't ask me for a date but if you want to play with it when it comes out, start figuring out how you are going to find the time :)).

TFS 2008 SP1 is going to be another fantastic release.  In TFS 2005 SP1, we started the tradition of adding small, tactical features that address common customer requests or enable delivering new value out of band.  In TFS 2008 SP1, that practice has gone into overdrive and we are delivering a ton of great new stuff for you.  Keeping with the theory that an SP should always be better (more stable, faster, etc) than what came before it, we continue to focus on tactical "low risk" improvements that are primarily based on customer feedback.  We leave the big game changing, major new scenario features for our major releases.

I've blogged a bit about what is coming in Rosario (our next major release); you can read some of our Rosario specs and you can check out our CTPs but that's not the point of this blog post.  I'm going to start blogging more about Rosario in the next couple of months.  For now I have so much great stuff to tell you about TFS 2008 that I can't imagine bothering you much with stuff that still a good ways down the road.

In addition to a long list of bug fixes (which I plan to publish when we get closer to SP1 release), there is an amazing list of new features.  The new features in TFS 2008 SP1 include:

Version Control

• Add to Source Control - The Add to Source Control dialogs have been improved to make them easier to use and more scalable.  This include such simple things as adding a menu option to the context menu on the folder tree.  Also, the add experience has been turned into a wizard with the first page allowing you to select what you want to add and the second page making it easy to review what you are adding and filter out things that don't make sense (.pdb, .exe, etc.)

• Drag & Drop - We've added the ability to drag files/folders from Windows Explorer (and other file drop sources) into the Source Control Explorer to add them.  This ties in well with the new Add to Source Control experience.  We have not yet added the ability to drag from the Source Control Explorer yet but if that's something you want, say so and we'll see if we can get it in a future release.
• Version control of unbound files - One of my personal favorite new features...  Have you ever noticed that if you start typing in a version controlled file that is in an open solution, it auto-checks out and lets you keep typing?  If the file is not in a solution you get weird read-only behavior.  No longer!  We now treat all version controlled files equally whether they are in the open project/solution or not - providing auto checkout, diff, and all of the other version control behavior.  This makes it so much easier to work with version control when files outside the solution get loaded.
• Simpler working folder mappings - I suspect you'll know what I mean when I say the "Workspace" dialog is not one of the more easily understood parts of TFS.  We have now added abilities to the Source Control Explorer so that you rarely have to look at it.  You can now right click on folders in the Source Control Explorer and map working folders, cloak mapped folders or unmap working folders.  This is an easier and faster way to change where source is stored on your local hard drive.  To further simplify this, we have added a link to the path bar in the source control explorer to indicate that no mapping has been created for a folder and give you a 1 click way of setting it.
• Checkin date/time column - We've gotten quite a few requests for a check date/time column in the Source Control Explorer.  The feedback has been heard and now you have it.  Ultimately we'd like to make the whole columnar display configurable but alas... that's for another day.

• Local Path is now a link -   The Local Path header in Source Control Explorer is now a link that allows you to easily open Windows Explorer to the folder.
• Editable source location - The field that displays the server folder in the Source Control Explorer is now editable to make is easy to change to a new folder by just typing rather than navigating the tree view.
• Download files to a stream - If you build TFS extensions, this can be a handy addition.  Instead of having download files to temp files and then read them back in and manage deleting the temp files, you can download directly in memory and process the contents.  I'm expecting some cool new Power Tools later this summer that will take advantage of this new feature.

Work Item Tracking

• Ribbon support for Office 2007 - Instead of the uglier "add-in" experience that you now have with TFS 2008 & Office 2007, we now have clean and easy to use ribbon support for all relevant TFS operations.

• Easily email work items - We've added support to Team Explorer to make it very easy to email a work item or a list of work items.  If you have Team System Web Access, these emails will contain links to it, giving recipients a great ability to explore related work items.

TFS Build

• Easily locate TFSBuild.proj file - We added a right click menu item on the build definition in Team Explorer to take you to the TFSBuild.proj file in the Source Control Explorer.
• Conditionalize builds on the trigger - We added the ability for a build script to detect how it was triggered so that you can have slightly different behaviors for CI, sheduled, manual, etc builds.
• Detect test result - Rather than just failing the build, you can now detect the results of tests and conditionalize the build script on it.
• Dynamically created properties - Dynamically created properties in the build can now be passed to solutions/projects.
• Reduce build log noise - Eliminate "noise" created by project to project references.  Now you will only get 1 message about each.
• Query build definitions across Team Projects - Added an object model API for querying build definitions across Team Projects.

Visual SourceSafe migration tool (vssconverter.exe)

We have received a significant number of reports of problems trying to the the vssconverter to move from VSS to TFS.  In TFS 2008 SP1, we invested very heavily in testing and bug fixing.  In addition to the few high level things I've called out here, we fixed many dozens of bugs - many of which were reported by customers.  We have also invested heavily in testing - collecting more than 20 customer VSS databases and making sure that the vssconverter handles them all seamlessly.  I strongly recommend you use this new vssconverter over any previous version.  I believe you will have a significantly better experience.  If you still have problems, we most certainly want to know about them.

• Elimination of namespace conflicts - Properly convert files where a file was deleted and a different file was subsequently renamed to the same name (and some similar scenarios).  This is the #1 most common issue that people have had with the current converter.
• Automatic solution rebinding - When converting a source tree, automatically change the binding in all solution and project files to bind to TFS rather than SourceSafe.  This eliminates a time consuming post conversion manual process.
• Correction of timestamp issues - Many VSS databases contain timestamp inconsistencies (due to VSS using a client timestamp rather than a server one).  The converter now adjusts for this problem rather than getting confused.
• Improved logging - The conversion logging messages are now more clear and provide more information necessary to diagnose what is wrong when the conversion process needs attention.

Other areas

• SQL 2008 support - When we released TFS 2008, it was compatible with SQL 2008 builds that were available at that time.  Unfortunately, in the interim, there have been changes to SQL 2008 that broke TFS.  TFS 2008 SP1 includes the necessary changes to work with final SQL 2008 builds.  There will be a few "special" steps for installing TFS 2008 SP1 with SQL 2008.  Keep your eyes peeled for a newer post that gives the details of installing TFS 2008 SP1 with SQL 2008.
• Team System Web Access links - If you've ever clicked on the link next to a filename in a checkin notification mail, then you know the feeling of disappointment :)  Unfortunately it doesn't give you the information you want.  With TFS 2008 SP1, if you have Team System Web Access installed, those links are now alive.  You can directly view the changes using the TSWA diff viewer.  This isn't the only place we've added the links - we've added TSWA links to many of the notification mails (work item changed, etc).  Overall a much nicer experience for people who don't live and die in Team Explorer.
• # of projects per sever - Constraints on the number of projects per server have been written about quite a bit.  In TFS 2008 SP1, we have made some important improvements.  To refresh your memory, the primary issue is that the size of the cache that the TFS client downloads is proportional to the number of projects on the server.  This cache can get very large (10s of MBs) and slow things down to the point that usability is affected.  The changes we have made for SP1 include:
• Only download metadata for projects a user has access to.  By only granting access to the projects a user needs, it will dramatically reduce the size of the metadata they download.
• Implemented cache compaction to remove some stale data from the cache that is no longer used.  We have seen 30% or better improvements from this in some circumstances.
• Improved the speed of the Connect To TFS experience when there are a large number of projects in the list.  We saw about an 80X improvement on one of our internal servers.
• Create Team Projects with a script - This has been a popular request since we first released TFS 2005.  Now you can do it.  You still must have Team Explorer installed on any client you want to use to create Team Projects, however, it can be scripted.  There is a new Visual Studio API (I'll blog a sample in the near future) to do this or, even more easily, you can use a new command "tfpt createteamproject" in the March 2008 release of the TFS Power tools to do this easily from the command line or a batch file.

Performance & Scale

• Improved syncing identities from Active Directory - Our tests show syncing a group with 200,000 users dropped from 69 minutes to about 10 minutes.  This can significantly reduce background overhead on a system with lots of users.
• Improved checkin concurrency - Checkins are globally serialized - meaning 2 checkins (overlapping or not) must be processed in order and the second must wait on the first to complete.  In SP1, we were able to both improve the overall speed of checkin and reduce the blocking.  The blocking period is now only about 1/3rd of the checkin time.
• tf branch /checkin - Creating new branches when they are large (ours are about 1,000,000 files) can be very time consuming.  We have created an option for creating a branch that is much faster.  tf branch /checkin creates the branch without first pending the changes and requiring a subsequent checkin operation.  The result is about a 10X improvement in branch creation speed.
• Online index rebuilding - If you use SQL Enterprise with TFS, TFS will now rebuild indexes online allowing for less "downtime" for maintenance.  If you use SQL Standard (which comes with TFS), then you will still get offline index rebuilding and your TFS server will not be responsive during weekly maintenance jobs.  If your TFS database is small, it doesn't really matter but as it gets into the terra-bytes, online index rebuilds become a must.
• Team build support for very large checkins - In TFS 2008 and previous versions, a very large checkin (hundreds of thousands of files) would trigger an out of memory error in TFS Build and prevent CI builds from triggering.  The out of memory issue has been fixed in SP1 and all checkins should properly trigger builds.
• Faster security manager - We found an O(N^2) algorithm in the security manager for version control and have replaced it with an O(N) algorithm.  It will help version control performance across the board.  We found it on large Get operations (getting hundreds of thousands of files).  The change reduced the security manager time from 5-6 minutes to a few seconds.  The end result is that those gets were about twice as fast.
• tf get /remap - Kind of a complicated feature but dang handy if you need it.  This is a new option on tf get that is intended to be used when you want to switch your workspace from one branch to another in the same code base.  You first change the workspace mapping and then issue a tf get /remap.  Because a large percentage of the files in two related branches are frequently identical, this command optimizes for that.  Rather than downloading all the content, it will only download the things that are different between the two branches.  I can reduce the get of a very large workspace from 10's of minutes to a few seconds.
• Much, much more... - This is just a taste of the performance improvements we've made.  As always, each release includes a roll up of performance improvements we've made for our own internal dogfooding of TFS.  This release is no different.  There are dozens of additional fixes that we've made to improve performance.  If your installation is very large, you should notice nice responsiveness improvements across the board.

As you can see, we've packed a lot of value into this service pack.  I hope all of this makes your days just a little bit better.  As always, we'd love to hear your feedback.  At this point, the service pack is just about done, so I can't take a bunch of new feature requests and get them into this release but we can sure put them on the list for the next one.  I'll let you know as soon as the Beta is available and I'm eager to hear you feedback.

Brian

On June 30, Microsoft will discontinue Windows XP in an effort to force all PC users onto Windows Vista.  As this date gets closer and closer, they have stubbornly insisted that they will not change their plans.

Last week, Microsoft CEO Steve Ballmer blinked, but in a rather confusing way:

• The sensible part:  Ballmer claimed that they might reconsider their decision if that's what customers wanted.
  
  
• The confusing part:  Ballmer appeared to be completely ignorant of the multitudes of people publicly begging for XP to get a stay of execution.

Just want kind of customer feedback would Ballmer be able to hear?

It's really not that hard to find overwhelming evidence of large numbers of people who want to continue using XP.  A simple Google search for the string "save windows XP" results in over 200 thousand hits.

Oh yeah, I forgot -- Steve probably doesn't use Google.  Maybe the problem is that he just can't find any XP fans on the Internets?  :-)

Or maybe Ballmer is following the now fashionable trend of counting an Internet person as only 3/5 of a real person?

• Sure, Ron Paul has lots of fanatical supporters, but they're mostly just people on the Internet, and they don't really count.
  
  
• Sure, Barack Obama has raised truckloads of money, but he mostly gets it from people on the Internet, and they don't really count.
  
  
• Sure, over 170 thousand people have signed the Save Windows XP petition, but those people are on the Internet, so they don't really count.

Or maybe this is simply the most arrogant corporate decision in history?  Maybe Steve can hear all of these desperate cries but he simply doesn't care.

Power corrupts.  Every monstrously large organization eventually turns into, well, a monster.  The next step is for all these organizations to start borrowing each other's tactics.  Hey Steve, why not start waterboarding everybody who won't switch to Windows Vista?  Apparently it's legal.  :-)

The whole situation is most annoying to those of us who are running small software companies.  Unlike Microsoft, we actually have to listen to our customers.  When they tell us to jump, we ask how high.

Microsoft is telling millions of its customers to jump.  Out of principle, I am doing my best not to comply:

• I'm typing this blog entry on Windows XP.
  
  
• That instance of Windows XP is actually a VMware image running on my Mac.  I started using a MacBook Pro with Leopard a couple months ago.  And I love it.
  
  
• I just donated fifty bucks to the ReactOS project.  I'm figuring that in the long run, I've got a better chance of getting Windows XP from ReactOS than from Redmond.

Some of my readers are horrified at this blog entry.  "But Eric, aren't you a .NET developer?"

Yes, I am.  My overall posture toward Microsoft is still friendly.  I still use Windows every day.  I still love Visual Studio.  C# is still my favorite language ever.  Heck, I'm even a big WPF fan, so I'd actually prefer to see the world switch to Vista.  I've used Vista, and while I didn't find it to be a compelling "must-have" upgrade, I rather liked it.

But none of this means that I'm going to give my blanket agreement to every decision Microsoft makes.  In this case, I object to Microsoft's plan, not because Vista is so awful, but rather, because ignoring customers is so wrong.

This is an evolving web version of a book that I'm writing titled "Zero to Hyper Agile in 90 Days or Less." If you have the time to read it straight through, that would be great. If you don't have the time or inclination for that, how about picking a section or two and leaving your frank feedback? Any and all feedback will be appreciated. Many thanks to all who have commented so far!

The end of each section of the "book" links to the next section.

Table of Contents

Introduction
Agile in a Nutshell
What is Agile?
Primary vs Secondary Benefits
Agile Development, What's in it for Me?

The Problems With Traditional Development
Dev Team Having Performance Problems? Try Niagra!
The Chinese Finger Trap of Traditional Development
The Chinese Finger Trap: Architecture, Development, and QA

Short Iterations
Unconciously Agile
Natural Law
Agile Development is People Oriented
The Agile Waterfall

Hyper Agile Development
There is no Bug. It is Not The Bug That Bends, it is Only Yourself
Apply Elegant Architecture to Your Dev Team
How Agile Solves Problems

Hyper Agile Lifecycle
Agile Product Management
The Role of Defect Management in Agile Development
Designing Software is the Same as Predicting the Future
Frequent Releases Improve Code Quality Faster
The Role of QA in an Agile Project
The Role of QA in an Agile Development Project Part II

Integration
Multi-Stage Continuous Integration

Releasing
It is Better to Find Customer Reported Problems as Soon as Possible
Customers Don't Want Frequent Releases
Tuning the Frequency of Your Release

Complimentary Practices
Refactoring and the Law of Unintended Consequences

Bibliography

More to come!

Previous: "Apply Elegant Architecture to Your Dev Team: Part I"

When you are creating new software, what do you think about? Don’t you think about how it will scale to meet your needs as they grow with high availability? Even if you don’t achieve that on the first try, you are still thinking about it and striving to achieve it. You know that to do it, you will need to make the right technology and architectural choices. Over time, you may need to change some of those choices to keep pace with competitors. Even if your current needs are modest, software development architecture has evolved technologies and patterns to allow software to scale from a single user to hundreds or even thousands of users on multiple platforms at multiple locations with 99.999% uptime.

If you consider your development organization in the same way, how would you apply the same thinking? What technologies are you using? What is the architecture of your organization? Will it scale from its current size to double its size? Will it scale seamlessly to include new teams in new locations? What will happen if you acquire a company? When creating software, you want to design it so that it is flexible and adapts to new circumstances. The same should be true for your development organization.

Another way to look at it is how a particular process would fare if each of the resources available were available at seemingly random times for random periods of time. This exactly describes the world of Open Source Software (OSS). At any given time you have no idea who will be contributing on what or how valuable the contribution will be. You don’t know where the contribution will come from and in many cases you don’t even know who the contributor actually is. This is an extreme example of a development situation. Even though your situation is probably not as extreme as this, by using techniques from the OSS world you will be better positioned to handle unexpected events when they inevitably occur.

Problems are an inevitable and regular part of life. Examples include illness, job change, human error, flight delays, system failure, unanticipated market changes, and natural disasters. The ability to cope with these problems is one measure of the robustness of the organization.

Part of robustness is that as things scale up or down, the impact is minimal. Tools and processes should be selected and designed to work well together whether they are used by 1 person or 10,000 . At all times, it should always feel like each individual is part of a team which is no bigger than 12 people. If practices are not scaleable from 1 to 10,000 then people can develop bad habits that resist scaling. If you develop habits that exist in a scaleable framework, then it is more likely that scaling can and will happen as and when needed.

Next: How Agile Solves Problems

Yet Another Fad
We’ve heard it all before. The Segway, UML, Virtual Reality, TQM, object-oriented databases, Artificial Intelligence. Agile’s no different, right? Just the latest fad? That’s what I thought.

Back in 2005 I had my first run-in with Agile development. At a speaker’s reception, my blissful ignorance of Agile came to an end. I was surrounded by Agilists. They looked perfectly normal to me, but then they started to talk about the advantages of keeping track of requirements on 3x5 cards, pair programming, and lots of other crazy sounding stuff.

3x5 cards! Are you kidding me? What is this, the seventies? How can people who make a living writing software advocate the use of 3x5 cards? And what about pair programming? Two people sitting together all day sharing the same keyboard and mouse switching between coding and sitting on their hands, having to hear phone calls about the results of medical tests. Yuck!

I wasn’t just skeptical, I was outraged that all these people were trying to push this nonsense. Keep in mind that I work at a company that provides software tools to companies that are looking to improve their process. On the surface, Agile seems to be diametrically opposed to that. I felt that it was time for somebody to step forward and do something about it. I nominated myself. To gather evidence I read the books, talked to the experts, and attended the seminars. But then one day a funny thing happened. I had an aha moment and I realized there might actually be something of value buried under all of the rhetoric.

Traditional Development Scenario
Here’s what I realized. Let’s say you want to add new features to stay competitive. In a traditional project, you have a known timeframe for major releases. Too short and you’ll spend too much time on overhead, too long and you’ll miss opportunities. For the sake of argument, let’s pick a timeframe of six months and say that allows you to provide three “big features.” Marketing says the three features with the highest ROI are a Facebook plug-in, a Second Life plug-in, and an RSS feed plug-in.

Midway through the design process, marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. You think, oh well, nothing we can do about that now. Just after you finish coding marketing declares that the Second Life plug-in is going to be a complete flop and when can they get iPhone support?

Now that the functionality has settled down, QA starts writing tests and running them. Planning and development took longer than expected and the release deadline is looming. Testing time is compressed, QA concentrates on the most critical stuff and gives the rest a spot check. Here’s a mystery. If your full test cycle takes two days, why does testing take a month? The answer is that you aren’t really doing a month of testing. Problems have been creeping in all along the way that you are just now finding out about and it takes many test/fix cycles to expose them and fix them. Once the find/fix rate gets down to an acceptable level, you declare victory and deliver the new release.

Now Let’s Try Agile
For simplicity, let’s use two month iterations. You start with the Facebook plug-in. You plan. You design. You create a test plan while the code is being written. You discover potential problems and deal with them. You automate those tests while the code is being written. As the code is written, it is integrated, built and tested continuously; problems are found and fixed immediately. At the end of development, the only problems that remain are the ones that could only be found at the end of development. If you wanted to, you could cut a new release with very little overhead if you wanted to.

Marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. So, you start on the RSS feed support. Now marketing says the Second Life plug-in is worthless but iPhone support is hot, so you add iPhone support. During the whole process, you kept your options open. At the end you have produced more business value than using the traditional process, and you were in a position to start realizing that value much earlier.

I also realized that you don’t need to do any of those things that at first really turned me away from Agile. You can still get the primary benefits without resorting to 3x5 cards or pair programming and you don’t have to do frequent releases. These things are optional and you can use them or not according to your preference and circumstances. My advice to you is don’t pass by the opportunity to find out if Agile can work for you the way it has worked for others. I’m not suggesting you throw out your skepticism; try a pilot project!

Next: No Really, What is Agile?