I believe we have the same goal: Better Software. The alternative I am suggesting is a more holistic approach; an approach that Ritchie and Thompson of Unix fame would recognise. It starts with the assumption that programmers are highly skilled creative professionals with the ability to address both the big picture and the details at the same time. Such programmers are a cut above what we have comes to know as ‘coders’, who have a much more limited outlook.
This expansive role of "Software Creator" becomes even more challenging in a team context. In this setting, the programmer needs to augment his technical skills with ‘soft’ skills such as communication and collaboration. This explains why programming is so difficult, and why we often fail. There is no silver bullet, and it takes a multifaceted individual to program well. Producing such individuals requires investment and mentoring as is common in other highly skilled professions. Team members may still have differing strengths (e.g. J2EE or credit swaps domain knowledge, etc), but they must poses, at minimum, the ability to collaborate well in a team.
This type of collaboration is a soft skill that can be learned by example. Teams that value this skill and take the time to develop it, gain the ability to act seamlessly as one, giving the appearance of being as strong as their strongest link in any one area of expertise.
The result is Software that is modelled, architected, designed and coded as though it was produced by one mind. Through practices like common code ownership, pair programming, pair rotation, small teams, and high bandwidth face-to-face communication, a seamless solution can be created where the Conway effect is visible through its absence (or near absence). So a trait of a team operating well in this mode is a Conway effect that is hard to detect. A sure sign that the team is effectively acting in unison.
Extreme Programming goes into some detail on how to achieve this. In such a context many of the problems you describe in earlier articles are avoided, and since the problems do not arise, there is no need for specific roles or activities to resolve them.
Thanks for the opportunity to share this alternative point of view with your readers. I, and many others think we need to stop the proliferation of roles and get back to basics.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).