Like Steve Maine, I've recently switched to RSS Bandit from SharpReader as my news aggregator of choice.  My main issues with SharpReader were:

• It used up way too much memory (300,000 K vs . 24,000 K).
• It took too long to load, the toast notifications used to hang my machine (I know I could turn them off but somehow I never got around to doing it).
• No ability to flag messages for follow up.  Being time-challenged of late I really wanted to mark records that I could post on later but couldn't (except by using the 'lock' and hunting for it later).
• No way of counting how many feeds I subscribed to (not really important, but I wanted to know - turns out it's 280).
• It ate some posts once.  Luke fixed this one pretty quick, but I find it hard to get over a data loss.

I'd tried RSS Bandit in the past but didn't think much of it.  However, now it provides a solution to most of the above problems.  It's fast, very quick to load, has great flagging and searching support and I really like the ability to use my own style sheet to view the posts (I wanted to try Newsgator with Lookout inside Outlook, but I had to install them a few times so that they'd play nice together, and then I couldn't find an easy way to choose my own reading font).  Matt Berther comments on Steve's post mentioned JetBrains (the people behind IntelliJ and ReSharper) have an Outlook plugin, OmniaMea that supports blog feeds as well as NNTP, so maybe this is my ideal.

Some things that I miss from SharpReader in RSS Bandit:

• Like Steve, I don't like the default alphabetical ordering.
• The arrow keys to move up and down between posts.
• The space bar takes me to the earliest unread message, rather than the most recent unread message.
• A strange setting where the font is always +0.25 bigger than I asked for.
• I preffered SharpReader's ability to open the browser in multiple new windows to a docked browser (maybe there's a config setting I'm yet to find).

I'm an archive kind of a guy so I'd love to find some tool to convert my SharpReader archive to RSS Bandit. 

Are you confused about how all of the WS-* specifications fit together?  Hard to get your head around the WS-Alphabet soup?   3Leaf have a great Web Services Architecture Timeline graphic that makes it easy to see how the specifications have been created over time [via Ken Brubaker]

Although there are a lot of specifications, they have been built in a composable way to support secure, reliable and transacted web services.

Martin Gudgin points to the Working Group Draft of the WS-I Basic Security Profile.  I believe that the web services security will play a major role in increasing the adoption of web services in future.  It's great to see the WS-I behind a push for greater interoperability in web services security.

Web services security enables message level security, through signing and encrypting parts of a message, so that secure communication can be established even across public networks such as the Internet.  Increasing support and compliance for this security infrastructure across platforms and development languages will lead to even greater adoption of web services.

I'm hoping that they develop test cases that can be used to prove compliance to the standard, similar to those already developed for the WS-I Basic Profile.  In preparations for this Saturday's Web Services Interoperability Day Michele Leroux Bustamante has had to assume the role of 'human interoperability tester'.

Before TechEd San Diego I'm going to be presenting a SAML token issuer sample with Michele Leroux Bustamante as part of the Web Service Interoperability Day this Saturday.  The event is a chance to actually see interoperability happening, rather than just watching PowerPoint slides.  We'll be focussing on showing real code demonstrate WS-Security (now an OASIS standard that will be implemented with the release of WSE 2.0) and WS-Policy.

Getting the demos ready has been an international collaboration.  John Bristowe has been waving the WSE/Policy 'Pom Poms'.  Chris Haddad is doing the Java implementation with OpenSAML.

After the demonstration there's a panel discussion on the state of web services standards that should be very lively.

I missed this story during the week but apparently the Australian birth rate is so low that we're facing extinction.  To stop the decline the government are offering AU$3000 to procreate!  So my wife and I could have made some money if only we'd flown back to Sydney to have Hannah.

Even though Hannah was born in the UK it turned out she wasn't eligible for a British passport since my wife and I have time-limited visas.  So it was a toss up between Hannah becoming an Australian or a German.  Turns out the Australian High Commission are quicker at issuing citizenship (now I undersatnd why!) than the Germans, and since we needed a passport in a hurry, Hannah's now an Australian.

The most challenging part was taking a photograph that met the passport criteria.  Trying to get a two year week old to open her eyes, look directly at the camera while lying against a light background with no shadows or parent hands visible was incredibly difficult.  After several attempts we were managed to get a photo so Hannah has a passport and can be successfully authenticated at Airports around the world.

I've been quiet in the blogsphere of late because of a number of changes going on in my life.  As well as a new baby I've also switched jobs as well, taking up a contract as a Program Manger with Kalido.  I'm responsible for creating a .NET version of their product APIs as well as managing the Test Team, focussing on automated testing.

Kalido create datawarehouse lifecycle management tools.  The core product, the Dynamic Information Warehouse helps large multinational companies manage complex datawarehouses in a way that can adapt to changes over time.  They were the first company I interviewed with when I arrived in London in October 2001.  I was intending to interview with many more companies, but I was so impressed with their technology that I accepted their offer.  Originally I helped develop a COM version of their product API and now I've been invited back to convert it to .NET. 

I started last week and it is great to be back in a software development company.  I love the challenge of shipping products given limited time and resources.

While writing about Jason Bock's experience with XP I started feeling a bit bored with asking 'Does XP work or not?  Should everyone be doing XP?'.  I read Alistair Cockburn's PhD Thesis that presents a convincing argument that no one methodology will ever be the right way of doing things,  that clever teams will find ways of selecting their methodologies at the start of a project (he gives several key criteria) and that people are really the most important part of it (which is why I'm surprised that so many organisations fail to imitate Microsoft's well-known and documented hiring process).

No methodology is going to be a silver bullet

To me this is useful because it provides a framework from which to view XP and other methodologies.  So XP has some good practices in it, but the notion that it's the only way to do things, or that it will work on all kinds of projects and that all of the practices are required for a successful project is plainly silly.

Questions like 'Is Microsoft doing XP?' aren't really important.  What is important is that any development group thinks about what works, reflects on experience and experiments with new practices to see if they make sense. 

Big methodologies can inhibit reflection

Sometimes I think that the 'big name' methodologies are harmful because they reduce the likelihood that a team or project manager will reflect on their practices.  Methodologies are often attractive to management and project leads because they are packages as an easy solution to the difficult problem of thinking about what practices are best for a particular situation.  I know that RUP says you should customize the methodology to each project, but in reality I've rarely seen this happen.  It's much easier to just use the pre-packaged methodology than it is to think and reflect on experience to develop a custom methodology for each project.

Reflection and customised methodology are harder to market than a brand-name methodology

Saying "We're Agile" or "We use XP" is much sexier and easier to sell than saying "We understand a range of software development practices and use them to create our own methodology at the start of each project, based on the characteristics of the project and reflecting on our previous experiences".

I'm a big fan of the approach that Steve McConnell takes in Rapid Development where he presents a range of software practices that can be used.  For each one he details the amount evaluates things like potential to reduce schedule time, improvement in project visibility, effect on schedule risk, chance or first-time success and chance of long-term success.  The problem is that this isn't as easy to market as other methodologies. 

While I was writing this post I came across the following post from Bob Martin on the Yahoo XP Mailing List who seems to be saying that it's more important to focus on the practices and attitudes (such as the principles behind Agile manifesto) than it is on the brand names:

I'm noticing that the industry is adopting agile practices and attitudes without needing or wanting brand names. In the last year I've worked with a number of teams who started with SCRUM, or XP, or FDD, and who have since been picking and choosing practices from the other methods to suit their needs ... Instead of increasing specialization, the industry seems to be building a body of agile knowledge that it can use as a resource help them build something useful to them. It would not surprise me to find that in ten years the words Agile, XP, Scrum, and FDD have become synonyms.

Recently I've been reading Alistair Cockburn's PhD thesis People and Methodologies in Software Development.  He argues that people are more important than methodology, there's no one methodology that will always be right (and there will always be new ones coming along) and that successful teams create their own methodology based on the needs of the project and the people involved.  Here are the key notes that I took while reading it.

Alistair poses three questions in his thesis:

• Will there always be new software development methodologies, or will there be a convergence at some point?
• If there is a convergence, what are the key characteristics of the methodology?  If there is no convergence, how can project teams deal with the number of methodologies
• What's the relationship between a project's methodology and the people on the project.

Here's the essence of his results:

• Yes, there will always be new development methodologies.
• The best way to deal with a large number of methodologies is to help a team understand what to consider when constructing their own methodology for each project.
• The people on a project team are a 'first order construct' and are more important than the methodology involved.  The characteristics of the team will limit any effect of a methodology.

His thesis is mainly composed of articles that he has written over the years.  Here are the summary points from these articles.

Observations on methodologies and project success
He based a lot of these findings on his own research of teams.

[When interviewing successful projects] what I find striking about these projects is that they show:

• Almost any methodology can be made to work on some project.
• Any methodology can manage to fail on some project.
• Heavy processes can be successful.
• Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.

And elsewhere:

I ran the seemingly odd hypothesis that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken.

Methodology is irrelevant in small teams
A key concept is that one methodology can't fit all projects.  Team size is one aspect to consider:

… discussions about methodology are largely irrelevant in small-scale groups:

If the team consists of only two to three people, then the methodology as a distinct topic may be inconsequential. But as the team size grows, coordination issues become significant, and therefore more consideration must be given to the methodology.

Wayne Stevens of the IBM Consulting Group illustrated with the following anecdote:

If only a few drivers cross a large parking lot at night, when there are no other cars, it doesn't matter where they drive. The few drivers can arrange to avoid each other. As the number of cars moving through the parking lot increases, eventually it does matter. With increasing number of drivers, it becomes more important that they establish and follow conventions about parking, driving lanes, and stop signs.

How to select a methodology
When selecting a methodology, some things to keep in mind are:

• Team Size has a big impact on the methodology
  • The larger the team the larger the methodology
  • The more critical the system (the more important the lack of defects) the more important that the methodology is publicly visible.
  • Often there are two sizes that work for a project - small teams using lightweight approaches and larger teams using heavier approaches.
• The quality of the communication impacts the choice of a methodology
  • The richer the communication quality, the less need there is for bureaucracy.

People factors that contribute to a project's success
Things that impact the influence of people on a project's success:

• Communication.  The best way of communicating is face to face with a whiteboard.
• Tending to consistency.  It's important to have the discipline to keep working on a consistent way (when the natural inclination is to get sloppy over time).  This is also why high-discipline methodologies (such as XP) are considered fragile.
• Good citizenship and looking around.  Alistair's quote 'A common answer to asking why a project succeeded at all is: "A few good people stepped in and did whatever was needed to get the job done."'.  This is similar to Martin Fowler's concept of the wandering architect.
• People vary.  Methodologies need to fit the people on the team otherwise they will be rejected.

Barely sufficient methodology
Alistair looks at barely sufficient methodology.  He believe the following factors are sweet spots in these types of projects.

• Two to eight people in a room where they can communicate quickly and easily.
• Onsite customers.  The ability to get questions about the customer's requirements answered easily.
• Short increments.   Deliver a working set of software every 1 to 3 months
• Fully automated regression tests.  That give feedback as soon as possible.
• Experienced developers.  Experienced developers are much faster.

Recommendations
Every project need to develop its own custom methodology based on the characteristics of the people, the project's specific priorities and the technologies being used.  Other important criteria can include team size, geographic separation and project criticality.

It's important to have times of reflection where the team can think about how successful the methodology has been and reconsider and adjust their working conventions.

Jason Bock writes about his experience with Extreme Programming for the last year. I like retrospectives (see Johanna Rothman's blog on Managing Product Development for a good set of questions to use in a retrospective) and people reflecting on experience and thought some of his observations were useful.

Things he likes:

• TDD and refactoring - makes it easy to change the code knowing that tests will pick up any problems.
• Pair programming because it gives quicker feedback on the work as it's being done.

Things he doesn't like:

• Stories. He thinks that the concept is too vague and there isn't enough investigation given to system requirements
• Feeling of it being a religious practice. It's better to treat them as a set of practices rather than religious commandments.
• The coaches often refer to 'the scriptures'. Jason says 'it's weird to hear the XP coaches that the company brought in for these projects to say "Well, the XP process says …".' rather than considering what practices might work.
• He thinks it's harder to get a pulse on the project as a whole. This is interesting as would have thought that the frequent iterations would have generated some

Overall I like the sound of Jason's pragmatism when he says that for him it's a lot more important to 'get it done!'. I've always liked the question 'what do I need to do today to make this product ship on time in future' (I think I read this in Microsoft Secrets years ago).

I'm presenting the Connected Applications: Security Basics talk at TechEd San Diego (vote now in the TechEd survey if you're attending). As part of the run up to the event I'm going to blog about some wider security topics, starting with the human aspects of security.
 
Although it's attractive to think that cryptographic techniques can provide perfect security this can never be the case where systems involve humans. The Art of Deception: Controlling the Human Element of Security by Kevin Mitnick illustrates this well. It is a book about Social Engineering, the practice of getting people to do things they wouldn't ordinarily do). It shows how easy it can be to circumvent an organisation's security through manipulating people.
 
The key point of the book is that natural human instincts to be helpful, avoid confrontation and respect authority can be easily used by a Social Engineer to get around an organization's security. Using fictional scenarios the book demonstrates how a Social Engineer can work. Some of the techniques involve posing as a fellow employee or a new employee requesting help. These techniques are often combined with sounding authoritative and being under time pressure ("I'm the new personal assistant to the CIO. I need to get the figures for the last quarter to the CIO for a presentation tonight otherwise I'll lose this job, but I can't open the spreadsheet on the network - can you help?"). The book also shows how easy can be easy it can be to get innocuous information (operating manuals, managers names, department codes, employee numbers etc.) that can be used in later communications to sound trustworthy and reliable.
 
The book demonstrates how the telephone and fax are great Social Engineering tools because they limited built-in authentication. It's easy to appear as someone else over the phone. In a large company with many different offices or a call centre it's possible to talk to someone you don't know personally and few people would think to validate the person's real identity.
 
Education and training are required to avoid falling victim to these techniques. The difficult part is that the attackers can take advantage of basic human instincts while victims have the harder task of acting against these instincts. The book finishes with a sample security policy for an organisation and flow charts to illustrate how to handle requests for information. This is useful but demonstrates how concerns about security need to be balanced against the ease of doing business (e.g. never take a message for a colleague from someone you don't know personally). I believe the threat modeling and risk-based approach are more useful techniques in helping an organisation come up with a security policy that successfully balances their security risks with their business practices.

The book's story approach did become a little tiresome at times, but overall I was impressed to see how humans are often the weakest link in a security system. While some of the stories involved high-tech techniques, such as hacking into the telephone exchange, others were simple cases of using influencing techniques to manipulate people.