Tuesday, October 31, 2006

Why are all great developers not the best Architects and vice-versa?

I have seen lot of exceptions though.

First the philosophical spin. Michael Plat says that Architect are analytic thinkers and programmers are logical thinkers and hence the mis-match. He gives a simple test to figure out whether you are a Architect or not. I failed the test but I still believe that I have excellent Architect’s prospective. :)


I think that real issue is that strong programmer fails to abstract or trivialize certain aspects of system. They are too involved in details and thus , are unable to see the system from 18000 feet.

As Survic said, "abstract a little -- not too high level, but a little bit higher than programming - "design pattern."

If you abstract too high, it is time to ask your management to promote you to astronaut or ivory-tower architect designation. Don’t mistake me, I don’t have any contempt for them. I do think that Corporate needs them also very badly.

7 comments:

survic said...

Architects are political animals. We need architects for the exact reason that we need “process”. Successful architects are not really “technical” – just as successful project managers. Of course, it depends on companies. Successful architects motivate and energize developers to do 95% of the work, and simply bless or justify, sugar-coat, and rubber stamp it. It is like a good palm reader … As an architect, you should always be ambiguous; as a developer, you should never ever take the words from an architect literally. Architects are philosophers – perhaps that is why you say they are “analytical". However, I do not believe those “multi-dimension things” – those are all crap. It is not that “analytical vs. logical”, it is “philosopher vs. science” -- architects need to ambiguous, so that they can buy the time for developers, while at the same time motivate them.

The key of being ambiguous is not to use the concepts from one source – if you do that, it is very easy to be nailed. Mix the terminologies, add your own interpretations and publicly announce that is the case – this will obtain two goals: make you a creative expert, and keep your words ambiguous.

I am not cynical -- I am actually describing how successful architects work, and I love working with architects. As a developer, to work with architects, on the one hand, you need to challenge them a little bit by asking them to use only one terminology system, and ask them to be accurate. On the other hand, you should let them do their thing -- let them fight for more design time, so that you can eventually get a few prototypes done, and then let them bless those prototypes. Do not interpret their words literally – you do not want inadvertently corner your friends (ya, you intentionally challenge them a little bit; but do not corner them)! Use their ideas as brainstorming tools, and then “just do it” -- getting the prototypes done is the most important thing. Preferably, there should be more than one prototype, so that the “blessing” can include “evaluation” and “combination of elements” (i.e., “design”).


I do not believe the model that "architects design and developers program", just like that I do not believe "project mangers plan and programmers code according to the plan". In reality, there are the other ends: programmers identify the dependences, estimate the duration, and project managers “only” record those facts and coordinate them. The same happens to “architects”: developers do the design (“prototyping”), architects “just” rubber stamp them.

Perhaps reality is in between.

Sure, some architects are very hand-on, then, that simply means they also wear developers’ hat.

I know my point of view is controversial. I also believe DBAs do not drive table design for new databases. DBAs are, by their very nature, “conservative”, they cannot “develop”, therefore, they cannot drive new table design.

Note that they are “conservative”, because they do not see users directly, they do not know “use cases” directly.

As a result, the core of the development is, well, developers. Development is driven by, well, developers, not business analysts, project mangers, not architects, not DBAs, etc.

I understand that some business analysts, project mangers, architects, and DBAs are very hand-on and development-oriented, then, they are just wearing developers’ hats. There are up side and down side for that, but that is basically it: they are doing developers job.

I am not against all those other members; I request their existence, and that they help and coordinate the corresponding aspects. However, it is developers who are doing the hand-on work – if that is not the case, then, it means those members are wearing developers’ hats.

Vikas said...

How does Dilbert get it so right ?
http://www.dilbert.com/comics/dilbert/archive/dilbert-20061105.html

http://www.dilbert.com/comics/dilbert/archive/dilbert-20061108.html

survic said...

My goodness, a picture means thousand words – still, allow me to put some words here: that is the exact reason for using contractors and doing outsourcing. The whole process can be named as “Process”.

survic said...

I should say, that is a humane and corporate way to do it ;-)

Vikas said...

I think that lot of confusion about responsibilities of Architect comes around the fact that there are two types of architects i.e., Enterprise Architect and Application Architects/Senior Programmer/Lead Programmers/Project Lead. Lot of organization has not demarcated these responsibility clearly and hence the confusion.

Lot of people of overlook the fact that you require application Architect to mediate between Enterprise Architects and Developers as discussed in this hair-splitting but excellent article by Andy Schneider http://www.devx.com/enterprise/Article/32036

I agree with your views on Enterprise Architect. We certainly need Enterprise Architects
1. To view things from 18000 Feet/Ivory Towers/Space Stations and facilitate construction of EAI/SOA/Workflow intensive applications by sharing technical information between teams and make sure teams have the necessary tools for cross-team efforts.

2. To make sure that there are no duplicate technical efforts across the teams in an Enterprise

3. Give philosophical/technical direction to enterprise/corporate

survic said...

I like it that it says: (architects and programmers) "we are all designers". Programmers are designers, not just coders. The problem is that "manufacture metaphor" does not recognize this.

Of course, it is not just management, some programmers behave like a coder, or assembly line worker -- they internalize what management told them -- talking about self-fulfilling prophecy.

Anonymous said...
This comment has been removed by a blog administrator.