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...

8 Comments

  • Isn't it the Product manager or some position like that who decides what features are actually in/out?

  • As already mentioned in some of the other comments, the decision is usually made by a Product Manager.

    The Product Manager should gather the requirements for the product and assign them to each release. The input of the board, architects, sales, customers etc is very important in this process.

  • All: I agree that the product manager has a say in this too, but isn't it so that the chief architect can only do his/her job well, if the architect can make the decisions, and based on advice from others for example? The reason I mention this is that if a PM is responsible: how can the PM make decisions if every decision could have architectural consequences which can only be overseen by the architect, AND, the work of the architect can only be done properly if the architect knows what to architect in the first place.

  • Frans,

    You mentioned that the next version of LLBL will use WPF. Do you think WPF is "ready" for VS to use it as the editor? Is it going to be fast enough? Can anti-aliasing / clear-type be disabled?

  • @pbz: v3 will use WPF for some designers, but the overall UI is still winforms. One reason we didn't pick WPF for the main UI was that the designers in VS.NET crashed too much (sometimes with vs.net). Crashing IDEs is a killer for productivity. The set of controls available for WPF is also not that mature.

    So for a 3rd party developer, it's perhaps not the best choice, now. For MS, it's different, if something crashes due to their own fault, they can fix it right away.

    The cleartype issue is indeed also a big pain. You can fix that a bit with pixel alignment controls but it's a pain nevertheless. Makes you wonder if WPF is meant for pixel-based computer screens...

  • In a good organization decision on what goes and what doesn’t' in a version it’s not a single person decision it’s based on a joint considerations of cost vs. benefit performed by a number of people with different views and job descriptions. It's a job of an architect to show the cost of any feature what is considered it's also his job to show benefits of a technical/architectural features what he or his technical team is proposing. He can't present a benefit of a non technical feature for this purpose company has product manager.

  • Well that's a software editor pattern...

    Juste too compare with the industry I'm working in (fiancial software); the issues are even worst :
    On the left corner, you have the technical engineer (Developpers mainly)
    On the right corner you have the business expertise (portfolio manager, standardisation groups, business analysts...)

    And I'm stuck in the middle..
    Well it is quite enjoyable and finance is almost as interesting as development.

    However, it happens that offen you are the guy who says "no".

    Well the fact is that you can't just "put a face" on a title.
    G.e : you need to send fix messages to whatever counteparty.
    Here you will find :
    Business content (refreshing positions, trade workflow, order management, compliance...)
    Technical content : Messaging, caching, distributing

    If you don't have a clear vision of everything required on the business level you could probalby issue what Frans calls a "Framework of Framework".

    However if you don't have enough technical knowledge on this, you won't be able to answer to your client if it is possible or not.

    Even worst, when it comes to finance :
    for business oriented people; IT means "underdog just good to write code"
    For IT, business oriented people means "Egocentric user with little brain."

  • Who made the decision, I always figured it was marketing.

    As for VS what would their to do decide on? You have to include the ability to develop for all the newest versions of Microsoft products, then include features of the newest version of the dotNet framework, finally look at the products that marketing is pushing the most and make sure to fill in holes that developers are complaining about.

Comments have been disabled for this content.