Is being a generalist really a good thing?

Let me get one thing straight before I start! Although I pay particular attention to design and usability issues I'm a generalist by nature. I fit to where ever I'm needed in a software development team; I'm just as happy coding as I am designing architecture or creating GUIs and I wouldn't want it any other way!

Of course being a generalist has it's problems, although I pride myself in having a pretty good understanding of software engineering principles, processes, architecture etc. by definition I can't know the nuances of the subject that a person with a specialism in that area knows! Today, I find myself coming up against just such a problem!

I've been part of a team which has written a website that outputs the whole of its data (screen text and database derived data) in the form of a XML document. This is then transformed against an XSL document thus separating the business and design layer, a sound architectural decision (well not quite there are a number of drawback but I'll leave that for another time). Rather unsurprisingly loading the XML stream and XSL document into an XML DOM each time and then transforming them each time is starting to cause a bottle neck in our web server's performance. After spending a little time researching about optimising the XSL (the static part of the equation) I've realised the I'm missing whole parts of understanding on the DOM and on XSL template! Also, I'm pretty sure that I could optimise the data retrieval and the following transformation to XML process to boot! How did I/we get into this problem?

In my experience being a generalist works well when in small scale or non-critical projects but when the stakes are high, people with specialist skill should be employed to make sure that security, performance, design and architecture are sound. Does this mean that a generalist should not work on high-stake projects? No because if we're honest there are one or more areas that we specialise in. Mine is user focused design , in such a situation we should play to our particular strengths rather than building by committee, having ill informed developers making critical decisions.

Where does that leave the companies who want *all* their developers to do a bit of everything instead of specialising. In my experience the products they produce are not as good as those produced by a team of people who are focused on their own area's - middleware, GUI's, databases etc. I'm under no illusion that having a team of specialist is a golden bullet to successful software projects, all team have there own problems such as communication but I am pretty confident that that product that they produced is considerably more robust, with better performance then anything a team of pure generalist can come up with!