Frans Bouma's blog

Generator.CreateCoolTool();

This Blog

Home
About

Syndication

Search

News

Navigation

About me

Fun stuff I created

My work

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

Published Friday, November 21, 2008 11:04 AM by FransBouma

Filed under: .NET General, Visual Studio, General Software Development

Comments

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 6:24 AM

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

Brett

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 6:48 AM

The architects are supposed to set an overall strategic goal, direction, and road map for a system. It is their responsibility to oversee that new development pushes the system in the right direction. How exactly the the road map is executed are influenced by more practical things, like project and funding infrastructure, as well as user response.

Anti-Architect

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 6:55 AM

Where I have always worked the Product Managers are the ones who decide what goes into a release. They are usually the ones that have direct contact with customers. It is up to the Architect to advise the Product Managers on things like if it is technically possible to do, if it will fit into the present architecture, and roughly how long it will take to develop. The Architect then interfaces with development group to determine how to implement the functionality and comes up with initial design. They also work with development to tackle any technical challenges that arise. So in this situation the Architect have very little say on what functionality shows up in a release, they can only try and pursued the Product Manager’s decision. If the Product Manager is strong then there is little influence if the they are weak then the Architect may be able to a strong influence. All ties go to the Product Owners who will usually side with the Product Managers because of their contact with the customers. This is how it has been in the companies I have worked for.

Dave

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 10:42 AM

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.

Philip Wagenaar

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 10:50 AM

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.

FransBouma

# re: If the Chief-Architect doesn't decide... who does?@ Friday, November 21, 2008 7:49 PM

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

# re: If the Chief-Architect doesn't decide... who does?@ Sunday, November 23, 2008 8:34 AM

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

FransBouma

# re: If the Chief-Architect doesn't decide... who does?@ Monday, November 24, 2008 1:25 AM

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.

Michael

# re: If the Chief-Architect doesn't decide... who does?@ Wednesday, November 26, 2008 7:01 AM

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

Frédéric

# re: If the Chief-Architect doesn't decide... who does?@ Thursday, November 27, 2008 3:51 PM

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.

will