If the Chief-Architect doesn't decide... who does?
Yesterday I read this great article about VS.NET's technical roadmap, posted by Rico Mariani. Rico is the Chief Architect of Visual Studio, and he explains what that title means as follows:
I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects. Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release. So, while it's true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap.
If Rico doesn't decide what's in the package, then... who does? And more importantly: how can a person who's not the chief architect, decide what's included in a version? Aren't decisions about what's in a version fundamentally important for the architecture of a version? I think it is, despite the fact that everything is done as modular as possible.
Of course, another question arises: why is the chief architect not given the right to decide what's in the version of VS.NET? Interesting team management, if you ask me. For example: if for feature group X, the system itself (the VS.NET framework) has to get a new subsystem, and X isn't included, the new subsystem is unnecessary. I wonder if Eclipse, with its relatively small team works the same way...