What do you call the people you write software for?

For most of my career I have referred to the people who I write software for “users”.  It just made sense, they are using the software so they are users?

Interestingly enough at Amazon we call them customers.  Not to say that the word user has been stricken entirely from the vocabulary, but it makes me wonder if it should.  Here is my thinking.  Something different happens in my mind when I think of the people I am writing software for when I use the word customer.  It is hard to describe…but maybe this story will help you understand what I mean…

When I worked at Microsoft I worked in the consulting division and we would help people make sense of the variety of ways to write code on the Windows platform.  Often times some of my customers (aka clients) would have come up with a unique way to solve a problem using some piece of Microsoft software.  When I would relate this back to the product team (another aspect of my job).  More times than not the question I would get back would be “why would they do that – that is not what we intended”.  We used to refer to this as the RDZ – reality distortion zone; which was the invisible field that hung over Redmond that prevented the product teams from understanding how people really used Microsoft product.

When I think about how a customer centric Microsoft would have been different – then the response back to me would have been something like “that is really cool, we never thought of that – how can we make it better”.

Try it.  It may just change the way you think about things.

If you smelt…you dealt it

nofartNo this entry is NOT about flatulence.  Ironically, there is a Wikipedia page that is – here.  Instead my intent is to opine on the practice at my employer about developers supporting their own code – which means that if you broke something then you are going to be the one to fix it.

When I was managing the production support team at my previous employer; the team’s responsibility was to focus on the operation of key systems and ensure that they were available and meeting SLAs.  This team did a good job at keeping things moving – if something broke they got to be pretty adept at fixing issues.  If you look at this as an outcome with a fixed cost (which is how we structured it) then it can look pretty attractive.  But in the end the people on the team had many concerns/issues/complaints/etc about the challenges they faced in sustaining this model.  In the end – I feel that this model takes too short of a view of life cycle of a system and therefore is flawed.

amazonlogoFirst it is worth noting that Amazon has a list of core leadership principles that they live and breath by.  I have done a lot of chin rubbing around these as of late and the more that I play with them the more I like them.  When considering this post there were a few in particular that I felt applied…”Ownership”, “Invent and Simplify” and “Insist on the Highest Standards”.  If you read the short descriptions for each of these they are all pointing to how separating support from development is flawed.

If developers are not responsible for keeping their own code running or seeing how it behaves in production then how they doing any of these things?  Sure it is possible that you get outcomes in this direction; but it is not likely – especially without the ownership.

A related topic to this is how we work this into our Agile methodology to ensure that we still get things done on time.

Firehose Treatment – Open Wide

I needed to take a short bit of time off from blogging while I worked out the details of interviewing, negotiating and relocating (at least me) to Seattle from Connecticut.  I am now into my second week of work at the largest online retailer and the fire hose is blasting full force.

Being this big means that someone has already done a lot of bernsteinbookthinking about how to make something massively scalable.  Back in “the day” I remember pouring over the Principles of Transaction Programming book by Bernstein.  I knew this stuff inside and out and it still serves me.


Given the massive need for scalability I have had to dust of some new/old theories. ACID is out BASE is in.  Sure I have read about a bunch of these over the last few years, but it is different being at a place that is actually doing it.

Here is a list of things blowing my mind today…

  1. Eventual Consistency – It will get there when it gets there.
  2. Anti Entropy – Anything with the word entropy in it I find confusing.  So what is Anti-Entropy? :-0
  3. AWS – I had to pay for this before, now everything we deploy is already running on this.  Note to self; shutdown my services and save a couple bucks.


I was recently helping some colleagues think about interviewing techniques. I like to see work product from people. So a while back I developed an assessment that we use. It has been a big help in evaluating candidates.

When I worked at Microsoft we took our interviewing very seriously. Certainly there are lots of stories (myths?) out there about the process. Some truer than others. I have a master list of good questions and suggestions I still use from that time. It is helpful to review periodically to just get into the right mindset.

Along these lines…I was recently turned onto InterviewZen. I like the idea of being able to watch a recording of someone creating a work product. We have a classic computer science sort of problem (weighted graph) that I use, but I don’t get to see the person working thru their thinking. I am going to try and adapt mine to this format.

Keep It Simple (kiss) Revisited

I have a calendar from a vendor we use that has some of the classic coding and design principles – one for each month.  I was rubbing my chin staring at it this morning and I wanted to share what popped into my head…

While I am sure that the KISS principle has been written about (perhaps to death) I had another instance of this today as it applies to operations and infrastructure.

Quick background – I recently inherited an Operational group.  Operations is the clean up crew of development here.  While I understand the rationale of separating them, I think I like the idea of developers supporting their own code so that they better understand the impact of what they do.  What a great teaching tool – you want to not get up in the middle of the night – fix the code, do a better job in the first place, write a utility to help you out.  We have a bunch of applications that have been around for years and over time the developers who maintain many of these have moved on.  So today I asked the question of someone about two AD groups and what they are used for.  In both cases the answer was initially I don’t know – and later the answer became these are not used anymore.

Part of keeping systems simple is getting rid of the things that are not used anymore.  We have all these extraneous moving parts that we don’t need.  This just creates system bloat that should be easy to remove.

Granted you cannot get to everything – right now.  But this stuff has to get cleaned up over time.  Putting it into some sort of maintenance, wish list or Kaizen log seems like an easy thing to do.

All it takes is discipline.

Agile Musing

I was at a LOMA meeting for work last week and was talking to a couple of other attendees about their Agile practices.


It reminded me of some early thinking I was doing back in the 90’s.  I was always drawn to doing things in what people now call an Agile way; but the first time I heard someone actually put words to what I was thinking was a presentation Jim McCarthy did at the 1995 Microsoft Global Summit in San Diego (I think).  I used to have the video on tape but it seems to be long lost at this point.  I found a couple YouTube excerpts but not the who thing.  He went on to write his book Dynamics of Software Development which elaborated on his 21 rules (I think the book has 40 something).  I remember liking his style…oh yeah…and the content was good too. 🙂

The Pragmatic Programmer is another book that put more meat on the bones of things that I was thinking or struggling with.  I consider this a timeless book unlike the Peter Norton’s Programming Guide to PC book (the pink shirt book) I recently came across in my archive.Norton

As I reminisce I am reminded about the Agile Manifesto which at first made me laugh but after that tickling feeling passed I took the simplicity and truth of it to heart.  I attached the image I keep on my desk here for posterity.


Not sure what the next Agile is going to be.  I do feel like there is something still missing that  I can’t quite put my finger on.  Hmmm.

Things that were once hard

I needed a quick utility to generate a script for setting the permissions on a massive (wide and deep) directory structure.  The analysis for this was not going well – I asked someone else to try it and they did not get the scope of the issue.  I needed to just get something running quickly so I wrote a quick .NET app to generate what I needed.  I was pleasantly surprised when went to actually grab the permissions for a given folder.

The last time I did something where I was scraping permissions off a folder I was in C++ and the Win32 API.  Yikes!  High impedence for something that I was just going to throw away.

The following is a snippet of code that wrote doing in .NET 4 (I don’t think this code would be any different in .NET 2).

 class FolderPermissions  
   public string Name { get; set; }  
   public IEnumerable<Acl> Acls { get; set; }  
 class Acl  
   public string Name { get; set; }  
   public FileSystemRights Permission { get; set; }  
 private static FolderPermissions GetFolderPermissions(string pFolderName)  
   AuthorizationRuleCollection perms;  
   perms = SafeCallToGetAccessRules(pFolderName);  
   var retAcls = new FolderPermissions { Name = pFolderName };  
   var acls = new List<Acl>();  
   foreach (FileSystemAccessRule perm in perms)  
     if ( perm.AccessControlType == AccessControlType.Deny)  
     var acl = new Acl() {Permission = perm.FileSystemRights, Name = perm.IdentityReference.ToString()};  
   retAcls.Acls = acls.ToArray();  
   return retAcls;  

This snippet is where I am copying the permissions for a given folder into my own lightweight structure, so that I could do queries on the structure to help me create the script.

One thing in particular I remember about doing this in Win32 was once I got the SID for a particular identity, it was a pain to resolve that to a name.  Now it is just the IdentityReference.Value.

This is the type of value I like.  Now if I just had a scripting language to do this in so I did not have to compile it would be all set.  Of course there are bunch out there – just I am not as proficient in them as I am in C#.  Hmmm.

IIS 7.5 and 2 Level Auth

We use a large vendor application at work.  We host all the infrastructure for the application inside the firewall, so there is absolutely no access from the Internet.

In IIS6 we configured 2 level authentication – NTLM and Forms Auth.  The vendor requires Forms Auth for the application.  Given the importance of this application and sensitive nature of the data; I also enabled NTLM and secured the site to only people in our division (about 450 people).  There are about 150 logins in the application meaning that 300 people have access to the site; even though they will not be able to actually see any screens until they login.

Through a series of discussions with different audiences; it was decided that there is still enough of a risk of those 300 people being infected with something that takes advantage of cross site scripting or other classic vulnerabilities.  So I further locked down the site using a more restrictive group.  While I feel like we are being a little paranoid about, I capitulated.

Enter IIS7…


Our standard for servers is Windows 2008r2 so we are on IIS7.5.  Doing this same 2 level authentication on IIS7.5 did not work.  Why?  Well because of the integrated pipeline…it simply cannot not do both at the “same time”.  One has to come first.  In IIS 6 NTLM always came first since that was done my IIS and then Forms Auth since that was done by ASP.NET.

There are a couple of hacks out there that describe how to work around this.  One of which I found posted here by Mike Volodarsky (formally of the IIS team).  Here he talks about a way to make this work by splitting up the authentication and forcing one to happen before the other.  I was up until well after midnight last night trying to consider how I would make this work given that the application is a vendor application and I don’t have the source code.  Not to mention that everything is precompiled, signed and obsuficated.  All of which add up to…this would be really hard to hack.

Finally, after a bit of chin rubbing…I came to the conclusion that the integrated pipeline may not be the problem at all.  Why do I even still need NTLM?  I mean if the only way for someone to access a web page on the site is to have a valid Forms Auth token then do I really need to force them to also have an NTLM token?  I went to bed content that I just need to leave NTLM behind in this case.

Now I just need to convince everyone that was pushing the original requirement for 2 level authentication that I don’t need it anymore.  Being that they don’t really understand the technology very well – that could be a challenge.  Since the way we got here was through a vulnerability scan of the web site in the first place – perhaps requesting another one will demonstrate my point and I won’t have to make them understand the why.

I will post an update on the outcome.

TFS Recovering Shelveset for Invalid User

One of the developers on the team was getting a TFS error (below) yesterday while trying to access a shelveset for a developer who left the account a couple of months ago.  Turns out he needed some of the code on the shelveset.

 TF50605: There was an error looking up the SID for TC30014  

Note to self…shelvesets are probably not the way to do this, thinking that a branch would better construct.  I want to encourage them to be doing more of these anyway.

The problem is because TFS is going to lookup this user in the Active Directory and the user does not exist anymore.  I can see the shelvesets in TFS using either TFS itself or TFS sidekicks.  I included a screen print of all the active shelvesets for this user in sidekicks.


So TFS must be doing some lookup on the user and when it does not find it – errors out.  Not knowing how to solve this, I put couple of searches later (“tf50605 -vssconverter”) out there and found this article.  While not directly what I needed it was enough information to crank up SQL Server Management Studio and start poking around a bit.  So I started with the OwnerId for user that was removed and for the user who was trying to get the code.

 SELECT IdentityId FROM tbl_Identity WHERE (DisplayName LIKE 'ad2\TC30014')  
 SELECT IdentityId FROM tbl_Identity WHERE (DisplayName LIKE 'ad2\RMxxxxx')  

Once I had this I plugged the deleted user’s id into the following query to get all the workspaces.

 SELECT TOP 1000 [WorkspaceId]  
  FROM [TfsVersionControl].[dbo].[tbl_Workspace]  
  WHERE OwnerId = 276  

This showed me a bunch of workspaces.  What I noticed is that evidently the shelvesets and workspaces are used in a similar model based on the type.  So a little bit of infering and playing in TFS and it looks like if I hack this table, I can reassign all the shelvesets to a valid user (which is sort of the spirit of the article above).

Leaving out some of the details, I ended up with the following query that reassigns the orphaned shelvesets (type=1) from one owner to the other.  Since the WorkspaceName is part of the primary key (and relatively short), I changed the name so that the new owner could distinguish between his shelvesets and those that were reassigned.

  UPDATE [TfsVersionControl].[dbo].[tbl_Workspace]  
  SET OwnerId = 123,  
    WorkspaceName = RIGHT(WorkspaceName + '-Reassigned',64)  
  WHERE OwnerID = 276   
    AND Type = 1  

Looking back at TFS Sidekicks (I verified it first in SSMS – wink) I could see that the more recent shelvesets had indeed been reassigned.  Sucess!!


Now granted, we are on a relatively old version of TFS; so this hack may already be obsolete. But I wanted to put it out here just in case.

Step Away From the Keyboard

My career has been undergoing a sea change lately. I am doing much less programming and more SharePoint. Not just SharePoint as a technology but applications/solutions built on SharePoint. Sure I may need a little code to pull something together, but not as much as I once was writing. Not to mention that I am being asked to take on more management responsibilities. On one hand this feels like a bit of a “promotion” on the other hand I feel myself slipping further away from the truly technical side of things. Which is kinda scary.

Up until the last year or so; I have been pretty technical. But now I find those MSDN magazines piling up on the nightstand. I just read some of my favorite programmer blogs and just scan the code. Sure I understand what and why these guys are doing, but I am not doing it myself. I used to be coming up with patterns like this myself and now I just read about them.

Being technical is a great security blanket; don’t like what your doing or where you are doing it? Just leave and go someplace better.

It does not feel like that now; things are starting to pass me by. Ouch. It’s chilly without my binky.

Since I have a lot to learn in this new role, whatever you want to call it; I will probably have to be with my current position for some time while I figure out the patterns for doing this job. Doh! What do you mean I can’t leave? I have to stay and learn this stuff no matter what? Doh! Doh!