I've spent more time this week installing components I've worked on with a team who are using them in their project.  This is a team of Java programmers who are moving across to .NET.  It's been interesting to see how difficult they are finding it.  Most of the problems are down to the way IIS/ASP.NET handle security on boxes that have been locked down, and the complexity of their configuration files (we spent 2 hours on a problem due to a typo in a type name in one of the configuration files).

On the security permissions, I think it's excellent that Microsoft ship their operating systems in a more locked down way, but if you don't educate developers about what is going on then what tends to happens is suddenly the Everyone user and other important users get permissions like 'Full Control' over the entire hard drives. 

On the config files,  I remember Alan Cooper mentioning how only an engineer could have designed a computer keyboard where potentially pressing one key could change/invalidate the actions of all others.  It's like that with the config files - they are really powerful, but a single mistyped character can stop the whole system from working.  It would be better if there was some way of viewing the information (e.g. WSE 2.0 has a nice Dev Studio plugin that presents a UI for the config file), validating it, or at least easily separating different classes of information (e.g. a mistake in my logging configuration is less critical than a mistake in the user account that ASP.NET runs under).

After accepting the need for greater education and improved design, I think that the attitude of developers plays a key role in dealing with these issues within a project.  It's interesting how one person's feelings of frustration, negativity or anxiety can sweep through a team.  For example, I was trying to solve a problem to do with security access and had someone sitting next to me saying 'this is crazy, this is way to difficult ...' which made it very hard to focus on solving the problem.  When the issue was finally resolved there was more talk about how ‘stupid’ the system was than on making sure they understood why it occurred and how it could be fixed in future.

One particular danger in teams is 'magic' or 'superstitious' thinking - the bafflement when something that wasn't working is fixed.  This can lead to a feeling of hopelessness within the team - 'It wasn't working, then we did lots of things and now it just started working again but I don't know why'.

Getting over the feeling of hopelessness is key.  The starting point is to work from the assumption that nothing magical is likely to go on.  When the feelings of anxiety start it's important to focus on letting these go and focus on through the problem rather than worrying about the position you're in ('damn, I need to get this working now').  It's important to work on a model for understanding the problem - describe how you think it should be working, look for areas where this might be wrong and propose hypotheses about what's going on. Also, avoid stating the obvious 'we're stuck and nothing we're doing is working'.  Finally when things work again it can be worth backtracking to break them again in order to understand exactly what solved the problem (e.g. after overcoming the security problem we spent some time reproducing it just to make sure that our solution worked and our understanding of the problem is correct).

Unfortunately, working on development projects is harder than it should be.  It requires a lot of knowledge and education to get things to work sometimes (which is why we can ask for the large salaries).  Attitude plays a large role in how smoothly a project runs.  It’s important to avoid feelings of panic and anxiety and hopelessness by focussing on understanding problems and learning more about how it is working.   Then on the larger scale, campaign Microsoft to improve user education, event viewer messages, configuration tools and tools that make it easier to problem solve what’s going on at the lower levels.

I had my code review today.  After preparing hard for it, it went well.  We found one area where I wasn't handling all of the boundary conditions as cleanly as I could and another area where I'd overoptimised a loop and thrown readability and maintainability out of the window.

On the one hand, it's annoying to have someone else find a hole in my code, on the other hand, it's good to have found it and to have learnt something about how to make code better.  I'd trade the anxiety about 'opening my kimono' for the benefits of improved code and the learning opportunities any day.

Some of the 'learning points' I got from the exercise include the benefits of drawing a diagram to make a problem clearer.  We drew a matrix of possiblities for certain end conditions, then went through cell at a time and worked out what the outcome would be.  I'd initially tried to do it in code comments and had missed some of the complexity.  The other thing I appreciated was being able to bounce ideas of another person.  My dream is that XP practices and pair programming would result in more interactions like this.

Chris Sells' picked up ChrisAn's post about Myers Briggs Types.  Apparently ENTJ is a common rating for people at Microsoft - 'Field Marshals' who 'can't not build an organisation'.  Turns out I'm an INFJ (Introverted iNtuiting Feeling Judging) along with Operah Winfrey, Mother Theresa and Martin Luther King - wow ;)  My strongest emphasis was on iNtuition type.  Apparently only 2% of the population have this combination.

There was an interseting part commenting on difficulties people of this type experience determing their job roles:

INFJ'spossess a strong personal charisma, INFJs are generally well-suited to the "inspirational" professions such as teaching (especially in higher education) and religious leadership. Psychology and counseling are other obvious choices, but overall, INFJs can be exceptionally difficult to pigeonhole by their career paths. Perhaps the best example of this occurs in the technical fields. Many INFJs perceive themselves at a disadvantage when dealing with the mystique and formality of "hard logic", and in academic terms this may cause a tendency to gravitate towards the liberal arts rather than the sciences. However, the significant minority of INFJs who do pursue studies and careers in the latter areas tend to be as successful as their T counterparts, as it is *iNtuition* -- the dominant function for the INFJ type -- which governs the ability to understand abstract theory and implement it creatively. Source

It's funny to read about the liberal arts and science problem - I completed first year science (maths, physics, psychology, drama) before switching to arts (psychology, film production) and now working in IT.

In a first year phsycs class it was discovered I was the only person doing any arts topics, so I had come up to the blackboard and explain what happens to electrons orbitting an atom when they are heated up.  I explained the electron's behaviour in terms of a motivational theory about what the electron wanted to do.  The professor said 'but electrons don't have any desire, there's no motivation involved'.  I always learnt it by thinking about what it would feel like to be an electron.  It was interesting to realise I had a different view.

Mike Vernal, the PM on Indigo has a good article on what is a PM at Microsoft.  Some relevant points:

• He describes himself as a Technical PM, but that his role is essentially one of being a therapist.  He makes sure that people talk to each other.
• The PM role is quite MS specific.  He notes that it's interesting that MS spends so much money on PM's essentially to make sure that people are talking to each other.

" ... the common factor amongst all PMs -- PMs are facilitators of communication. The more gregarious, inclusive, and communicative a PM, the better. I thought I would have spent a lot more of my time on technical design work, but I'm actually ok with the communication schtick. At least it's not lonely."

Here's my story about Web Services and WSE that I gave to a Visual Basic User Group in Manchester last night:

• SOAP is a way of communicating over internet friendly protocols
• Web Services is based on simple standards that made it easy to get companies to commit to the standard.
• There were many gaps in the initial Web Service building blocks.  Now there are many specifications that plug the gap - the key is making it easy for developers and developer tools to adopt these specifications.
• WSE is the implementation of many of these emerging specifications.
• WSE makes it easy to secure web services without having to secure the wire through:
  • Encryption
  • Signing
  • Exchanging security tokens.
• WSE also shows some interesting new approaches:
  • Using policies.  Allows administrators or others to apply security settings without having to recompile code.
  • Addressing.  Introduces the idea of routing web services, allows developers to virtualise the network.
• The programming model may change in future, but it's likely that the XML on the wire will change less.
  • Luckily the programming model is relatively simple.

I also recommend Werner Vogel's article Web Services are NOT Distributed Objects.

All of the Tech Ed 2003 talks are available online.  There are some great presentations on WSE, including Keith Ballinger talking about WS-SecureConversation.  Presentations like these are useful for filling the gaps in the WSE 2 Tech Preview documentation.

Microsoft's ability to provide such a wealth of content is one of the main reasons I like developing for their platform.  What other vendor provides this level of its supports for developers?

I had an experience this week with .NET where most of the day was spent working with the configuration and setup rather than on the business logic.  I was working with a team to implement the web service security framework I’ve been developing.  There are a number of assemblies in the project – one http module, a metadata module and another with the WSE filters.    The team I was working with were trying to use the ‘Copy Local’ property of assembly references in Visual Studio to copy assemblies from a central third party assembly directory to the project’s local folders.  This was the root of many of our problems, as the better way to achieve this goal is to use the GAC.

We basically ran into problems because we redeployed updated assemblies to the local project, rather than the central third party assembly directory.  When we compiled our project it overwrote our updated assemblies in the local project with the older assemblies in the third party directory.  It took us a while to understand that this was going on.  We first noticed that the updated assemblies had been replaced with older assemblies.   We removed all of the references from Visual Studio but it was still happening.  A MCS consultant gave us some assistance and showed how to use Ildasm.exe to view the assembly manifest – this shows what the assembly knows about rather than what Visual Studio knows about.  This then helped us work out what was going on.

I really enjoy picking up tips using Ildasm.exe to see what's going on under the covers.  I find working around others is a great way of doing this.  Knowing what's going on under the covers takes a lot of work, but it's rewarding when the knolwedge helps solve problems.  Eric sink has just written a great article on the benefits of understanding what's going on under the covers rather than relying on higher level tools.

Tools like reflector and Ildasm.exe are great at getting a handle on what is going on under the covers.  Yesterday I read the readme to reflector and realised that you can use it to display which virtual functions are overridden locally in a class and which are inherited by the base class (shown by different coloured member names).  It’s also possible to search for all references to a member within the loaded assemblies.  I think this is the best tool for browsing projects – better than the object browser and the class view combined.  This screen shot shows how you can find sub types as well as seeing which methods are implemented locally (black members) and those that are implemented in base classes (green).

Tim Bacon has another good post on his blog about the techniques someone playing the coaching role in an XP team can use to persuade, influence and help other team members.  Similar to the idea of a Project Manager at Microsoft, Tim notes that an XP Coach often has responsibility without authority.  Tim's list is comprehensive and insightful and covers many of the techniques I studied in counselling psychology topics at University. 

I like the fact that he pushes using open ended style approaches rather than more didactic approaches.  Using more of a Socratic approach is a much better way of encouraging people to grow and develop in intellectual pursuits like programming.  I'm sometimes surprised by the level of posturing, ego and insecurity amongst many IT professionals - a lot of energy seems to go into defending a position of expert rather than into producing results or helping others with their knowledge.

It's encouraging to me that there are people like Tim out there who are focussed on using good communication techniques to help other developers achieve their potential.  It's interesting that he mentions listening is a key part of this.  I think it is a mistake that some developers believe that gruffness or snap-decisions are better than reflection, questioning and thinking.  I'm interested to know how Tim views the difference between the activities an XP coach might perform and those of a mentor.  I know on Tuesday night we spoke about one difference being that as an XP coach you also have to be a performing member of the programming team in order to garner the team's respect (through 'having skin in the game' in the words of Alan Cooper).

In browsing around tonight I also found an excellent blog entry from Morris Sims a Microsoft Employee on doing what you love.   He mentions the importance of having mentors that adapted to his strengths and weaknesses, making a bet on yourself and taking risks.  Ed Kaim also adds to this the idea of 'just doing it'.  I'm certainly taking this to heart at the moment getting out there and presenting to the developer community and extending my contacts.  I'm presenting on WSE again to a group in Manchester next week.

In other news, I had a great time today working with another developer to integrate work I had done into their project - it was another experience of pair programming, sharing knowledge, working efficiently and getting things done.

Last night I went to another Extreme Tuesday Club (XTC) at the Old Bank of England pub in London.  I've been attending for the last few months and the club's been going for over four years.  It's a free event open to anyone interested in extreme programming or agile development.

It's one of the most interesting and intelligent groups of developers I've met.  I know a lot of people might be turned off about a bunch of programmers talking shop in a pub.  However, I find that when people get together and share a passionate it's very exciting and interesting.  It's quite comon to see people pull their laptops out and start programming.  Many of them are active in the Open Source community - a great line I overheard was "sorry guys, go to go - I have to do some Open Source".

The people differ in their range of experience with XP programming.  Some members hold PhD's in Computer Science and have been doing XP since it began, others have read some books and want to know more.   In the past few months several key international figures have also dropped by including Martin Fowler, Erich Gamma and Alistair Cockburn.

Here's an indication of the kinds of topics I talked about last night:

• The strengths and weaknesses of strongly-typed and weakly-typed languages.  What are the relative merits of Ruby and Python? I also got my first insight into the 'two axes of typing - strong versus weak, and dynamic versus static'. Dynamic languages let you assign a value without declaring the type of the variable first (such as Perl and Python).  Perl is considered a weakly typed language because you can put another value type into the variable, whereas Python is a strongly typed language as it will only allow values of the original type,
• What does involved with the concept of a Coach in XP?  Should there be a designated coach in each team or should everyone try and help any other team member in difficulty?  The notion is that coaching is a process not a role.
• I met Tim Bacon, who bills himself as an XP coach, for the first time after reading many of his postings.  It was fantastic to hear someone else involved in programming talk about how 'emotions are what interest him most'.
• Sometimes the role of a coach can be to listen to someone and validate them, listening to their anxieties: it can be difficult to talk on this level to the managers or team leads.
• How to handle a situation where the project's success revolves around one key individual.  This was referred to as the 'Bus Test' - how many developers would have to be hit by a bus before the project was in trouble.  We discussed a situation where a key devloper had been removed from a project in order that the team and the project continue more successfully.
• Does a team celebration negatively impact future performance?  One group had recently delivered their project and had a day on a yacht as a celebration.  Their manager had challenged them - was the day of team building successful since their performance in the weeks since had been lower than before.  One point of view was that it wasn't the effect afterwards, but the motivating property of the reward prior.  Others felt that it was the motivating quality of the reward in the eyes of the other teams in the company.
• A discussion on Refactoring and the GOF books have made a significant contribution to the developer community.  Refactoring was really about the practice of what programmers do everyday.  Someone described it as like learning how to cook properly after years of reading a cookbook.  It's like if you are a brick-layer finding out there are different ways to lay bricks.  The benefit of the refactoring approach is that it is language independent - it's about why you do something. One of the most useful ideas in Refactoring is the notion of smells - a sense that the code has some problems. 
• A general complaint from many of the members moving from Java into C# is that Microsoft doesn't have good support for refactoring in C#.  The belief is that Microsoft are interested in the Visual Basic style developers who want to have GUIs and Wizards that help them achieve tasks.

All up a fantastic evening in the pub.

Rebecca Dias is a PM on the Advanced Web Services team.  She's shifted her blog to a new location.  She has a whole grab bag of WSE goodies posted on her blog from a Web Services conference day.

Tim Ewald provides a useful overview of how WSE fits with ASMX web services, Scott Short has a good PowerPoint on WSE Security - explaining about Security Tokens and WS-SecureConversation.

Best of all though are the two Hands On Labs used at TechEd 2003 and written by Aaron Skonnard.  The first describes how to use the SOAP TCP supports, similar to his previous article.  The second provides information on how to use WS-Policy to author policy for web services.  This is a particularly good document as this feature isn't mentioned in many places (yet).

WS-Policy and WS-SecurityPolicy solve the problem of tying code too closely to the security: controlling access to the code is a separate concern from what the code does.  With Policies it is possible to place the security information in a file instead of inside compiled code. So if you decide that a method needs to allow users in the 'Broker' role and not 'Traders' you can make this change in the policyCache.xml file, without having to recompile your code.

It took me a while to understand this.  My first attempt at securing web services with WSE was to set the Thread.Principal to a GenericPrincipal object that I created, and then use the [PrincipalPermission(SecurityAction.Demand,Role="Banker")] attribute above my method.  However, with policies, I can set this in a policy file, like:

<wsp:Policy wsu:Id="TradersOnly">
 <Integrity wsp:Usage="wsp:Required"
  xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
  <TokenInfo>
   <SecurityToken>
    <TokenType>UsernameToken</TokenType>
    <Claims>
     <wse:Role value="Traders"
      wse:xmlns="http://microsoft.com/wse/2003/06"/>
    </Claims>
   </SecurityToken>
  </TokenInfo>
 </Integrity>
</wsp:Policy>

Now all I need to know is how to get this working with a custom SecurityContext token (or how to achieve the same effect with a custom assertion handler).  In this case the role information is probably not going to be passed in the SOAP message with the SecurityContext token - it will be cached on the server, so I'm not sure how policy will work in this situation.  More study required ...

It's great to see Eric Gunnerson doing some usability testing on the default C# project templates.  He correctly spots that the:

I know this code has been around for a while, but Craig Andera's 'Last Configuration Handler I'll Ever Need' article is very useful.  He creates a class that implements the IConfigurationSectionHandler interface and uses deserialization to take the config file information and squirt it into a class.  It makes it simple to use a configuration section of a config file as well as making it easy to access these values from a class withoutout having to write any code to hook the class up.  Very nice.