An Instance of a Logical Fallacy

I collaborate with different individuals on multiple disciplines. Often, I propose my collaborators to venture into areas which I have got only cursory familiarity. We work with things which are fundamental in nature.  Direct "monetization" of things which I am interested in collaborating is difficult. and it is by choice. It often servers a mechanism for food for thought. Of course, It does posses some "intrinsic" value.


Couple of weeks back, while travelling to Bangalore, I happen to buy a book titled, "Rookie Smart", written by Liz Wiseman. The central thesis of this book is, most often, Experts are at a disadvantage against "Rookies", in modern day work place. She has clustered  Rookies with similar traits to "BackPacker","Hunter-Gather", "FireWalker" and "Pioneer" etc.

After doing some reading, I loaned this book to a collaborator of mine. After a day, he phoned me and asked a question which went as  follows, "If Rookies can beat an expert in most areas, what is the point of learning deep topics?". I was bit taken aback, after getting this response. . After a while, I did understand that, he has fallen victim to the logical fallacy monikered as "Affirming the consequent".


The fallacy goes as follows

A => B. B has happened, therefore A. ( If A, then B. B , Therefore A)

The book is about how a rookie can upstage an expert,in some areas. It is not about, experts are upstaged by rookies, everywhere. So, book never implies that there is no point in become an expert at something. A naive analysis will lead to some kind of "Nihilistic" view that, It is futile to gain deep expertise in anything.

Do you posses the temperament of a "Software Architect"?

Being a person who has got exposure to "mundane" Business Application development to Computer Aided Design (CAD) applications, I have considered myself to be  "lucky" to have got such kind of exposure. Good Technical exposure coupled with propensity to understand the business and people issues pertinent to the context, has given me success of some kind.

As I progressed in the Software Industry, people began to confer titles like Technical architect, Software Architect, Solutions Architect, Principal Consultant etc. I had considered these things only as a title given by the employers to reflect the compensation package I was offered. In the last few years, I have noticed that, these titles really does matter in the organization "pecking" order. The question which are often tossed across to me is, "How can one become an architect?" or "What it takes to be a Software architect?". I have not been able to give an answer to them, which have satisfied me. A definitive answer is also out of question.

A recent operational definition given me in a presentation slide went as follows.

Architect (n) –Any person who has “fooled” around in the Software Industry for sizeable time (ever shrinking span) who is past his prime,as a Programmer Or Engineer,Systematically moved up in the hierarchy to obey “Peter Principle”.

Sarcasm aside, I will try to give some case based reasoning. The following paragraphs has got certain bias towards enterprise application architecture.

For most of the evolved domains, there are standard idioms and practices which drive the whole state of affairs there. As a result of this, most people fall into the mundane and time tested work habits and end-up doing the same thing, multiple times over. Enterprise Application development is an area where time tested patterns are well known among it's practitioners and well documented as well. Standard terms like N-tier architecture, Separation of Concerns, View/Biz/Persistence Layer,Stateless Programming model, Asynchronous messaging, Resource tier integration, Horizontal scaling, distributed architecture, SOA, Model View Contoler  Architecture, MVP, MVVM etc. are tossed in most discussions about Enterprise Application architecture.

Most of the architects have "devoured" books written around Enterprise Application concerns. Some of the most studed are POEAA (Martin Fowler), POSA (Douglas Schmidt et al), EIP (Greg/Boby), GOF(Erich Gamma), DDD (Evans),PPP(Robert Martin) etc. Even though, the above books from the Industry thought leaders have helped us to have a "de-facto" lingo to communicate, often, trying to stick with the generic advice has led to lot of accidental complexity getting induced into the systems designed to blindly follow these thought leaders. A kind of "Cargo cult" Architecture.

IMHO, any Software Architecture/Design problem should understand the context and goals of the Solution. The Most important one are

• The Solution should be Simple, to the extent possible
• The Solution  should incorporate Functional requirements
• The Solution  should meet Non-Functional requirements
• The Solution should be able to incorporate change
• The Solution should follow well known practices and idioms 

As an architect, or being part of the group, the goal of architecture seems to be finding the sweet spot between these competing necessities. The context is the single biggest factor in the success of an architectural initiative. An Architect has to balance the priorities of Stakeholders, Peers, Team members, Technology SMEs , while designing the solution. An effective leadership style is also necessary to successfully come up with systems which can withstand the test of the time.

To be a good architect, one requires

• Good Technical skills ( Exposure to varied systems)
• Good Business acumen
• Reasonably good inter personal skills
• Knowledge of Good Architecture Stlyes and Idioms
• Domain Knowledge
• A "Rookie" mindset

Moreover, he needs to have an excellent team to back his effort!