Rants, rambles, news and notes from another geek

Edjez Is Back!

My good friend Eduardo Jezierski has returned to the blog-o-sphere. His new blog is up and running and his first post explains what he’s been doing at InSTEDD since leaving Microsoft.

He’s promised me that he’ll blog about all kinds of interesting technology and how they’re using it for really cool humanitarian efforts around the world.

Good to see you Ed and good luck on your mission!

Technorati Tags: edjez,instedd

List of Musical Works in Unusual Time Signatures

Haha… I love the Internet sometimes. I was sitting here in my office listening to the Tool song Jambi, tapping my foot along, counting the beats on a background thread as I am wont to do…

“Hmm… this is in 9/4 time signature. COOL!”

You see, I’ve always loved finding songs that have unusual time signatures. One quick search later and I found this little page over on Answers.com:

List of musical works in unusual time signatures

Cool. I’m gonna have to dig through my music for some of those.

Technorati Tags: Music,Tool,Time Signatures

Changes for Me

Someone pointed out today that I hadn’t been blogging lately (guilty as charged) and that I hadn’t blogged anything at all about recent changes in my work life.

A year ago, various personal and family issues led me to make a promise to my wife that I would move her back to Denver. We’ve enjoyed Seattle a lot, but with her Lupus and other things, she needed to be closer to her family. This led me to start looking around for opportunities that would let me get back to Denver.

Long story short, I have moved on from P&P and am now working as a Program Manager on the Visual Studio Team System Architect Edition product. This role will allow me to live in Denver and work remotely most of the time. I still plan to be back in the Redmond area every month or two, though.

We’re doing some really exciting stuff on the VSTS-AE product at the moment that I’m really looking forward to sharing with you all soon, so please stay tuned. I think I feel my blogging genes firing up again. :)

Happy Birthday Sis!

Happy Birthday to my wonderful sister Michelle. You are a great sis, a great mom, smart business woman and a good friend. Hopefully we can all get back together soon. Love you.


Heroes and Villains

Recently I was involved in a discussion of teams and roles and whether the ‘hero model’ is healthy.

In general parlance, the hero model is one where we encourage people to be superstars, to stand out, and to save the day. This is a common model in many companies and many people attribute individual compensation models as being the culprit.

Here is how the thinking goes. When you recognize and reward people for standout, rock-star, save-the-day behaviors, what you are really doing is rewarding people for not being team players. Or perhaps they are team players, but they are on a team that is more like a figure skating team than a basketball team. On a figure skating team, each person is individually judged and the scores are combined to create the team score. The ‘team’ doesn’t actually work together to achieve their final score.

A basketball team, however, doesn’t work this way. It is more like a machine where each moving part tightly meshes with the other pieces in the system. When one part fails or under performs, the entire team fails or under performs. As the old saying goes, “A chain is only as strong as its weakest link.”

Most agile-minded folks like the idea of basketball teams and don’t really like the idea of figure skating teams. Most agilists will talk about teams as if they are organisms. They will use metaphors like family, system, machine, and others, that show how the parts are all working together. Many non-agile folks will talk about team members as resources and describe the team in language that make it sound like the component parts are replaceable and interchangeable.

Now, lets get back to the idea of Heroes. The gymnastics team loves heroes. In fact, they depend on heroes. The team may all be made up of heroes in the ideal case, but there is always the poor schmuck who doesn’t have a good day, who falls, or who gets hit in the kneecap by an opponent’s boyfriend.

Let’s look at that a bit closer. The opponent in the famous kneecap case was a fellow team member. Was a Hero. She was heralded, along with the kneecapped skater, as one of the next great skating Heroes of her generation. But I would propose, and most would agree, that she was not a Hero. She wasn’t one before the kneecapping and she obviously wasn’t one after the kneecapping. She was a Villain.

If you think back to your comic book lore, there are some interesting characteristics of Heroes and Villains. Heroes are almost always reluctant. They don’t want to have to do what they want to do. For the most part, they just want to be regular folks. They don’t want to be different, or shining; they want to be just like everyone else. They’d rather be on the team of humanity than outside it.

Villains in the other hand love to light up. Love to be noticed and get attention. In fact, for most of them, that is their number one goal. They will engineer situations to get attention, to look better than the other guy and.. to get paid.

So here’s my assertion as it related to software development teams: The Hero Model doesn’t exist. What does exist is more properly named the Villain Model. Organizations that recognize, reward and encourage people to stand-out will create a system on Villains. We are engineers, and it is our nature to want to hack our way around obstacles to success. It is what we do. Presented with a system like we’re discussing here, some folks will eventually figure out that to ‘get ahead’ you have to compete with your team members. You have to stand-out, be a Hero, save-the-day, get the bonus, the gold star, the promotion.

But as I said, when you set out to be a Hero, you are almost always a Villain! You will go after the best projects, leaving the trash for others. You’ll sign up for the best work items, leaving the bugs for lesser mortals. You’ll avoid pair programming, because that is sharing the glory. You’ll try to ‘own’ key pieces of the system to protect your asset base. Some people, as we have seen in the figure skating story, will actually attempt to undermine their competitors by kneecapping them. Remember, Heroes are reluctant.

So… are you in an organization that rewards kneecapping villains? Are you a kneecapper yourself? If you aren’t, do you know who is?

P&P Composite Application Guidance for WPF

I completely forgot to blog this a couple of weeks ago, but Glenn Block, Product Manager for our UX/Client work, recently announced our plans for providing guidance (ala Composite UI App Block) for WPF applications.

A few important things from Glenn’s post for those familiar with CAB and our other assets in this space:

What is WPF Composite Client?

This is not a&nbsp_place_holder; new version of CAB . It is an entirely new&nbsp_place_holder; set of&nbsp_place_holder; libraries and guidance,&nbsp_place_holder; built from the ground&nbsp_place_holder; up, targeting development of new WPF Composite applications.&nbsp_place_holder; We’ll be working with both the UIFX and WPF teams, the same people who build the platform.

We are&nbsp_place_holder; not discarding everything that we did in the client space and starting from scratch. We’ve done a lot of work around patterns such as Modularity (composition), Services, Dependency injection, Event Brokering,&nbsp_place_holder; etc.&nbsp_place_holder; These concepts are&nbsp_place_holder; essential for&nbsp_place_holder; building Composite applications&nbsp_place_holder; and we will carry&nbsp_place_holder; them forward&nbsp_place_holder; into the new guidance.&nbsp_place_holder; However, you should expect their manifestations to be very different than what&nbsp_place_holder; you see today in CAB.&nbsp_place_holder; We’re not changing the APIs for fun. We think there are&nbsp_place_holder; numerous compelling reasons&nbsp_place_holder; to do so:

  1. CAB was not built to support WPF.&nbsp_place_holder; While you can get a n&nbsp_place_holder; application to work in WPF&nbsp_place_holder; using some flavor of CAB , you can’t make use of WPF’s full functionality. WPF is an inherently different paradigm than WinForms. For example,&nbsp_place_holder; RoutedEvents in WPF are entirely different than WinForm Events. Controls in WPF are look-less while in Win Forms controls have a specific look and feel, etc.
  2. WPF does not offer the “Drag” and “Drop” Win Forms development experience. CAB&nbsp_place_holder; development scenarios depend upon the rich tooling and productivity experience provided by Visual Studio.&nbsp_place_holder; The WPF developer experience is entirely different&nbsp_place_holder; and incompatible.&nbsp_place_holder; We feel that customers&nbsp_place_holder; will not succeed in mechanically migrating their existing WinForms applications to WPF&nbsp_place_holder; and should not try. There are no upgrade wizards&nbsp_place_holder; such as the VB6 to VB.NET migration tools.&nbsp_place_holder; The transition from WinForms to WPF requires substantial effort and most developers face a steep learning curve. For these&nbsp_place_holder; reasons, the new offering&nbsp_place_holder; will not focus on migration scenarios.
  3. We’ve learned. Over the years we’ve&nbsp_place_holder; received&nbsp_place_holder; great&nbsp_place_holder; feedback , positive and negative,&nbsp_place_holder; on&nbsp_place_holder; our CAB implementation.&nbsp_place_holder; We’ve heard&nbsp_place_holder; many times&nbsp_place_holder; that&nbsp_place_holder; it&nbsp_place_holder; is too heavy,&nbsp_place_holder; too complicated, too tightly coupled, too hard to grasp, etc.&nbsp_place_holder; Acropolis evaluators have provided new insights and suggested new approaches. We think the best way to address the concerns and tackle the new ideas – perhaps the only way – is with a clean break.&nbsp_place_holder;
  4. Win Forms is not dead. I’ve actually had emails from customers saying that Win Forms was being retired this year . This myth must be dispelled. Win Forms&nbsp_place_holder; is very much alive and there are future investments in Win Forms yet to come. Win Forms is the recommended breadth solution for LOB application development for the foreseeable future.

Read the rest of Glenn’s post here: http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx

Technorati Tags: P&P , CAB , WPF

TDD With PowerShell - Mocking Things

Recently, I’ve been dabbling with doing TDD in PowerShell. I think there may be a TDD Framework brewing in my head, but at this point I haven’t done enough to figure out what such a framework would look like. Often I find that the functions I’m writing depend heavily on built-in cmdlets and BCL types and there can be issues mocking them out when the underlying .NET type isn’t easy to mock out. This isn’t so much an issue with PS as it is an issue with .NET, but since PS is very close to the edge of the world (where the code touches the user), it can be hard to mock.

That said, as with most dynamic scripting evnironments, you can mock out a lot of things. Suppose you want to test a function that depends on get-childitem. Because functions evaluate before cmdlets, you can actually replace it by defining a function with that name:

function get-childitem() 
return @()

Now you have a naked stub get-childitem that returns an empty array. All is good so far. Next you need a gci that returns a single FileInfoObject and for your test you want to have the “archive” bit set on this file. You try to create a new replacement function for get-childitem:

function get-childitem() 
$fi = new-object System.IO.FileInfo("bogus.txt") 
$fi.Attributes = [System.IO.FileAttributes]::Archive 

But at this point you discover that you can’t set the Archive bit, because the file doesn’t exist.

This is actually a common problem we run into when we TDD up against another API that isn’t mock friendly. In an OO language like C#, I will typically wrap it up in another class & interface that I own and then mock out the interface for my code. This is do-able in PS, but a little more complicated because you may have to implement a fair amount of extra code to create and return a PSObject that has the interface you expect to find in your calling code. (This code can be a lot smaller, but less clear if you wantΓǪ I opted for clarity):

function get-childitem() 
$fi = new-object PSObject 
$getter = { return [System.IO.FileAttributes]::Archive } 
Add-member -inputObject $fi -memberType ScriptProperty -name Attributes -value $getter $secondValue $setter 
Return $fi

The challenge with this approach is the amount of code it takes to mock out all of the parts that you need. For example, if you need the Mode script property that comes built in to PowerShell for DirectoryInfo and FileInfo, then you will have to add them to your mock. If you also need to support the setter for the Attributes property, then you will need to add that (and possibly a Note member to hold the data).

As with all mocking exercises, this gets complicated when interacting with real things and since PowerShell is really about interacting with real things, it is hard.


Technorati Tags: Agile , TDD , Powershell , Mock Objects

Tabs in Vim - How Did I Miss This?

Yesterday John Lam did a keynote for the P&P Summit where he talked about the DLR, Ruby, Dynamic Languages and all that goodness. John is a smart, fun, engaging speaker and it was a great talk.

At the end of it I found myself wanting to run up on stage with everyone else to ask my question. But I decided against it. Because my question was WAAAAY off topic.

“How did you get those Tabs in your GVim widow???”

I figured with a bit of Googling I could find the answer and I did. It turns out that since Vim 7.0, there have been tabs you just don’t see them unless you ask for them.

Rather than rehash all the details, I’ll just point you to this excellent article on linux.com by Joe ‘Zonker’ Brockmeier:


Happy vimming! :)