The Ivory Tower Architect

In one of my recent project, client was afraid of doing some architectural changes.  The changes proposed were necessary and were for the betterment of the application.  We were proposing the use of some of the industry standard libraries, frameworks and tools.  Use of these new frameworks would make the code more maintainable.

In spite of the benefits of the proposed architectural changes, client was not really keen on doing those changes.

Why?

This question kept bothering me for sometime.  Digging a little deeper into the past, found that client had a bad experience with one of the architects.  They had hired an architect, worked with him for a year, but nothing fruitful came out of this engagement.  Sounds familiar?

Time and again I have faced this sort of a situation.  One of my previous post was on similar lines.  Be a Developer not an architect!

Googling a little I found a commonly used term for such architects.  Its called Ivory Tower Architect


What are the symptoms of Ivory Tower Architects:

Notice the usage of the word "symptoms".

According to wikitonary The meaning of "symptom" is 

"Anything that indicates, or is characteristic of, the presence of something else, especially of something undesirable."

Based on the above definition, you must have understood that Ivory Tower Architect is almost like a decease.  If it gets hold of someone, it does not leave them very easily.

Back to the original question.  The symptoms of Ivory Tower Architects:

• Loves attending meetings all the time.  He thinks, their job is to attend meetings.  If there is nothing to discuss, He will invent new reasons to organize a meeting.  Usually these meetings are very long, in fact He believes in "longer the better"
• Loves talking down to the developers.  He thinks developers are some inferior species.
• Loves to show off his mastery of software design.  When I say, "the mastery of software design", it means mastery in drawing pretty pictures.  Whether the design actually works in practice, is not relevant to him (Usually, the design won't work)
• Loves to churn out documents.  This person is like the printing press, continuously creates/updates documents.  He thinks, his productivity is measured by number of mail, xls and doc files created/updated in a day.  Not to mentioned the number of Minutes of Meetings he (or someone on his behalf) publishes every day.
• Forces the development team to implement the architecture he has designed
• Pretends that he is listening to your suggestions, but actually he is thinking about ways to reject your suggestions.  No matter how relevant your suggestion is, he will never accept it.  To do so undermines his very existence
• He will never ever work directly on the code himself.  He thinks that coding should only be done by mortal developers!
• Does not believe in the KISS (Keep It Simple, Stupid!) principle.

If you know someone who has these symptoms, please do not forget to send them a get well soon card (this is the best you can do)!  In case you can gather enough courage, tell them to stop goofing around and start doing real work!

Be a Programmer not an Architect!

In a lot of projects that I have worked so far, I have come across a situation where one/or more person/people act as an Architect to the project.

One would wonder, what are the responsibilities of these Architects? 

• They are supposed to see the bigger picture
• They are supposed to guide the project in the right direction
• They are supposed to give good solutions to technical problems

Time and again I have felt that, the intent is right! But, (there is always a but!) the problem is people take up the role in the wrong spirit.

A lot of architects that I have met, have stopped doing active programming. Most of their time is spend in attending meetings, calls and drawing some pretty diagrams.

You might think whats wrong with that?

Well, I think (and these are strictly my views), If someone is not in touch with programming then how can he/she suggest a sane solution to any technical problem?

If someone has left programming years ago then

• How can he/she solve any technical problem? 
• How can he/she visualize that there is going to be a technical problem implementing a solution that he/she is suggesting?

I think answer to all of the above questions is, they can't!

And I am making these claims out of personal experience.

First example:

I have worked in a project where some architect decided that, there is no MVC framework in the Java world that suites our requirements!

And the project ended up have its very own brand new MVC framework. This was not some project in 1980 (BTW I was not even born by then!). This was a project executed in 2009.

I don't understand that in 2009 how can one decide to write a new MVC framework?

One might thing whats wrong with writing a new MVC framework? Most important problem is, re-invent the wheel!

Lots of open-source projects have invested a hell lot of time and money in making sure that, a MVC framework does what its supposed to do.

If someone write an MVC framework, may be he/she is not aware of all the possible cases an MVC framework should support.

End result, a half baked solution that solves the "todays problem" but its no good for the future!

Another thing to consider is the cost: Who is paying for this framework anyways? Its the client of-course.

End result, software becomes expensive!

I think such wrong decisions make software expensive then it should have been. Client gets a piece of software that he never needed in the first place.

I think there must be at least 25 MVC frameworks in the Java world in 2009. I am sure at least a few would have fit whatever requirements we had.  Its just short slightness on the part of the Architect, to decide to write a new MVC Framework rather than finding one that fits the requirements.

Another example:

I had worked in a project where Architect's had decided that, we should not be using any types other than String's.

We had a few web-services to do various things in the project. One of them was to do payment. According to his suggestion, all arguments to the methods in payment web-service should be of String type!

Man! the first time I head of this decision, I was thinking, what the @#$%^&!

Imagine passing amounts as String and then in the web-service implementation converting them into proper types.

Imagine because of the fact that amounts were of type string, client's of web-service could pass "abcd" as the amount.

Hence, web-service implementation had to validate these values and throw an exception or return an error message stating that "abcd" is not a valid amount!

All that validation code and the mapping code is all waste!  It's just a big big big waste!  Something that was not required in the first place. Client paid for that code! (Its almost like distributing free money.)

Why did this happen?

Because the Architect was not in touch with Programming, he could not visualize the real problems that would appear because of this decision.

End result, maintenance nightmare, ugly code, overly complicated system.

I think in the end all I want to say is, Stay in touch with Coding. Coding is not a mundane task that anyone can do.

A person can become a good Architect iff (if an only if) he/she is a good Programmer!