Eric Gunnerson is asking whether they should change the default behaviour for displaying forms in Visual Studio so that when you double click on a file in the Solutions Explorer it opens either the code window or the form design window based on the way you last viewed the file.

I think he should definitely go with this idea.  I'm finding it so frustrating that the .asmx web service files are always opening on the designer view and I have to keep remembering to right-click or choose 'view code' from the hyperlink displayed on the designer.  I can't say much about straight forms as I haven't worked on a project that uses them heavily yet, but definitely for web services, defaulting to the format last viewed is an improvement.

Wow, this is cool, I just discovered through examining my referrers that Mehran Nikoo has a blog as well. This is great timing as I was just thinking 'I wish Mehran had a blog'.  Subscribed.   

Mehran is a switched on developer (he's taking holidays in order to come to the PDC, there's someone who knows who's managing his career!) who gave a great presentation on SOA (where are the slides Mehran?).  Mehran and his colleague Edward have written a number of good articles on developement on their company's site. 

He's also volunteered to provide a location where we can meet up and discuss the GoF Design Patterns in .NET (I know it's old school now that SOA is in favour, but they're still important within the right locations).  As he says, if you're in London and want to be involved, send us an email

I had an enjoyable day today working alongside Mark White, a consultant (and all round clever guy) at Microsoft in the UK.  Amongst other topics, Mark asked me a great question about the difference between Extreme Programming and Agile Development.  I said that I thought the fundamental difference was that XP was based on a more prescriptive set of practices (Test First, Planning Games, Paired Programming etc) whereas Agile Development was more a philosophy (based on focussing on the people issues of software development and doing things that worked).

At a drinks event tonight I spoke with a developer from ThoughtWorks who backed up my idea.  He said that one of the challenges was that Banks and Finance companies didn't like the idea of doing anything 'Extreme' so Agile was a better way of describing it.

I was interested to hear though that ThoughtWorks mix their Agile approach with large-scale multi-national development.  As the Agile Manifesto says, an Agile approach is about individuals and interactions over tools and process and customer collaboration over contract negotiation.  One of the key points of XP seems to be about communicating and talking with people, both within the team and between the team and the customers.  It strikes me that these principles may be challenged by large-scale projects worked on by geographically disburse teams (even if, as the ThoughtWorks developer said 'they are all clever people').

I also think there are great challenges with doing an XP approach on large teams.  In order for this to work I believe there has to be an overriding architecture that lets the large project act like lots of small teams.  To me large-scale projects with teams in different countries make it very difficult to practice agile or Extreme Programming.  Still, it's interesting watching ThoughtWorks as a test bed for Agile methods on large scale projects.

Mark also mentioned that the Microsoft Solutions Framework (framework, not methodology) could still add something to XP or Agile approaches with it's notion of the Team Model.   I particularly agree that these approaches could be improved with the role of Program Manager, but perhaps that's just my bias.

Keith Ballinger reveals why he's been busy lately - Bill Gates demos interoperable web services between Microsoft and IBM with an application that:

"links automotive parts suppliers, manufacturers and dealers via Web services that use new specifications to ensure security, reliable messaging, and transaction support." here

MSDN seems to have an excellent article that describes the application used in the demo (and more on the practical implementation of SOAs) titled Secure, Reliable, Transacted Web Services: Architecture and Composition. Omri Gazitts has more about the demonstration. 

Reliable messaging and transaction support are obvious features not covered by the current WSE 2.0 implementation.  I think reliable messaging is particularly important.  For example, the project I'm working with at the moment uses web services to poll a database to see when changes occur.  Reliable messaging would allow the web service to notify the client via a message when new data was available.

Ah, the fun of trying to guess at a new technology before it arrives.  It feels like the marketing buzz that surrounds a new film - the intense focus and speculation before an opening night.  Steve Maine is trying to figure out what Indigo is, Christian Weyer has a turn as well.  Don Box tells us it's a 'state of mind', which makes Steve think its a Zen-thing

I thought Don Box's talk on XML at TechEd 03 was the most revealing where he said the WS-* specifications are being created to support a messaging platform and bus (made me think of TIBCO) for the enterprise.  I think that Indigo will continue to support these specifications, perhaps adding wider infrastructure support and an improved object model for developers to access these features.  In terms of the object model, I believe that WSE 2.0 TP gives us a good idea of what will be involved.  It's interesting two that the pipeline processing model on WSE 2.0 is actually an approach to Aspect Oriented systems, where the Aspects are the pipeline filters.

Just my 2c worth.

I got these two books last weekend and both are excellent:

C# Data Security Handbook - a great read going through all of the support for data encryption, digital signatures and certificates in both .NET and the CAPICOM.  Full of excellent code-samples and useful explanations of the background theory.

Professional Design Patterns in VB.NET: Building Adaptable Applications - a good overview of the design patterns in .NET.  I would have preffered it in C# but it's easy enough to convert.  The start goes through about half of the GOF patterns and shows how to implement them.  The rest of the book deals with how patterns might help in different architectural tiers.  There's a good coverage on creating abstract classes for ADO.NET which allow you to use them without having to use a specific data provider.  I'm hoping to use this as an aid to a study group in future.

I just got back from a day and a half at the VBUG Annual Conference.  It was a really good event for networking with some interesting and friendly developers.  It's interesting tracking what's happening to VB6 developers.  A slow drift to VB.NET seems to be a common story.  There's also still the tension between various styles of developers - those that are into architecture and the deeper workings of the system and those that are still concerned with string concatenation performance and how to use ADO.NET.

The drinks reception was an excellent chance to catch up with other speakers.  It was fun to hear Bill Vaughn's Microsoft War stories (like receiving a pager message to stop criticizing Access while he was still giving the presentation).  Tim Sneath was entertaining on the topics of blogs and did a commendable job of dealing with various developers’ comments on Microsoft.  He also recommended SourceGear Vault as the best source control tool.  I agree with him that Eric's blog is a good read.

I really enjoyed meeting up with Edward Garson and Mehran Nikoo from Dunstan Thomas who did a useful presentation on Service Oriented Architecture.  They revealed that they'd had a social gathering recently where they'd watched Don Box's presentation from the XML Dev-Con.  I revealed that my mum knows who Don Box is after seeing those videos.  These guys did a good job of joining the dots on what I've seen and read about recently.  The big revelation was the idea of having a Service Agent in the Data Access layer of one application managing calls to Web Services provided by another application.

My presentation went down well, though I had been up late at night using Reflector to convert my demos from C# into VB.NET (Man, line continuation characters, automatic formatting around brackets and having to put the Inherits statement on a new line are a real drag!).  It was also a challenge to condense a two-hour presentation down into 60 minutes.  Many people came up and said they found it useful and interesting - security and web services seem to be a common problem (one guy I met had hand-rolled WS-Security in VB6 - it took all summer he said).  I also got two more booking requests for other regional VBUG groups.

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.