Some words of advice for the aspiring architect

Some advice to people who want to take up software architecture as a profession.

I won’t say that I am the perfect architect and I had followed all of this advice myself. Some of this I am still trying hard to implement myself and I have failed in a few occasions. But I do understand that these are the goals and I have to aim high to hit high.

“There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves.”

And some these lessons have been learnt by peeing on the electric fence. Yeah I have had very few people to observe and books like “97 things every architect should know” weren’t out there then.

Can I become and architect in the next 21 days, 24 hours?

No it is not possible to teach yourself architecture in 24 hours. May be 21 days. Well No again. Why? Read Peter Norvigs classic here.

"Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.

An architect should be able to work at / communicate at varied levels of abstraction.

If you are a hands on developer aspiring to move into the role – You should be able to ‘see the forests for trees’ or raise your level of abstraction when needed. This is a very helpful when

• You need to dive into an existing system and understand it.
• Communicate with stake holders without over whelming them with the details.

If you are into the role for sometime now you should be able to dive into the details when it is required. The devil is in the details :-). This is very helpful when 

• You are estimating / breaking down the system to provide commitments to stake holders
• Communicate with other members of the development team (you need to speak to a developer in a lower level of abstraction).

An architect should have knowledge in a breadth of technologies.

An architect should be a Jack of all trades. Do not misunderstand this quote, the full quote will probably be a better one

"Jack of all trades, master of none, though oftentimes better than master of one".

How can you learn all the technologies coming out today, especially that the technologies are coming out at a frantic pace?

Welcome to meta-learning. Learn things at a meta level, meaning both Windows Azure and Google App Engine are PaaS. If you learn them at a conceptual level and correlate the concepts between them it is easier. Same applies to .NET and J2EE. But if you do not know the underlying concepts, this becomes really hard and virtually impossible. Of course there will be nuances specific to a technology which you have to learn as well.

Remember the Golden Hammer rule:

If all you have is a Golden Hammer, everything looks like nail.

Use the power of networks, community.

Learn from the community, Contribute to the community. I will quote ayende here.

Another point that I want to bring up is the importance of professional networks to bring information to us. No one can really keep track on all the things that are going on in the industry, and I have come to rely more & more on the opinions of the people in my social network to evaluate and consider alternatives in areas that aren’t offering acute pain. That allows me to be on top of things and learn what is going on at an “executive brief” level. That allows me to concentrate on the things that are acute to me, knowing the other people running into other problems will explore other areas and bring their results to my attention. – from http://ayende.com/Blog/archive/2010/01/24/the-paradox-of-choice-best-of-breed-or-cheapest-of.aspx

It is the age of networks damn it, Use Twitter, RSS, Stackoverflow, Quora whatever…

The people who you work with are Important

If you are not working with bright developers who keep pushing you to the the next level, demanding managers who keep pushing you to the next level, You will be mediocre. Choose your colleagues carefully.

• When was the last you heard about a cool concept/technology from a colleague?
• When was the last you participated in a good tech talk as a team?
• When was the last your colleague suggested you a great article / book?
• When was the last when your manager suggested you a technology you have never heard of?

An architect should understand that time is not an infinite resource

Engineering is not about perfect solutions, It is about doing the best you can with Limited resources – Randy Pausch, The Last Lecture

You cannot design / architect every aspect of the solution to perfection. Instead an architect should identify what are the most important modules of the system and focus his effort on making them the best. Eric Evans talks about this under the head of Strategic Design.

As an architect if you make any technological mistakes, it is amplified because of the number of people who follow you

Do not learn on the job, learning is continuous and you should have to learn things before hand. Keep a practice ground,  may be a pet project, may be code & design katas. Even though this applies to any programmer, this applies even more to architects.

Sprint Zero is really important

People are good at emulating something that’s already there. So setup a good representative sample usage of the proposed architecture in code.

Know your limitations as an architect working from a vendor side @ an offshore location

Expect you to be heard less, having less voice in a few scenarios.

Learn to disagree and commit

This is the most important thing that you need to learn as an architect. Not always your opinion will be given a fair consideration (no matter how hard you believe it). You have the following options

• Learn to either disagree gracefully but still commit for the other alternative.
• Ask for forgiveness than for permission. Implement your solution and prove that it works better, anyone can raise objections to solutions in air (not implemented) but very few can resist the hard reality.

Learn when to quit

Since you have not become an architect in 21 days and became one through your hard earned knowledge there will be many occasions when other stakeholders (esp. higher up ex: Clients, Project Managers) will be hell bent on implementing what you think as the obvious wrong solution. If you too strongly believe in what you think should be the solution, explaining it and moving out of the solution implementation is a very valid alternative. Keep your ego in check in these scenarios and you have the options listed in Disagree and Commit. Remember that your stakeholders are too stressed that they start believing in laetrile, they are human too.

If you raise hell about a problem, they focus on you more than the problem. You become the problem.

You cannot swim against the current for long, you have to either swim with the current or swim out of it.

Expect to work for the worst

I know this is flamebait and a highly biased personal opinion. The sorry state of software project management is that people take up the profession because they cannot keep pace with technology any more. It is very likely that you will end up working for managers like that, prepare yourselves. Expect the worst; you won’t be disappointed if you end up working for one.

A corollary to that, when you do get to work with good Managers, do whatever it takes to be with them. The others might think you are insane / mad but it doesn’t matter.

If you are an aspiring architect / practicing architect and if you have stopped keeping up with technology, its time to quit the profession.

Stay on top of development

This becomes really crucial if you are hands on guy. Coding your modules as well as staying on top of other modules becomes really hard. Code reviews are a good way to understand what is going on in the rest of project and learning a few techniques from your team members.

Comment source commits into the Version Control System and have a Source Monitor like SVN Monitor, read the comments periodically (may be once in two days). Dive in to the source when needed. Reviewing every line of code is impossible, so pair with new members yourselves or pair new members with existing team members till they pick up the project idioms and practices. This can keep the review effort to minimum.

Automate mundane things using a static analysis tool like NDepend.

Bridge the generation gap

I have to do much better here. As an experienced architect (Since you have not become an architect in 21 days)  the people in your generation are likely to be your managers or other peers. The people in your team who you lead technically will be in the next generation. It is natural that you hang around with people from your age of development, generation of development (Those are the people with whom you can have discussions like – When we were programming in ASP / COBOL yada yada yada). This widens the generation gap further and alienates you. Connect across generations. As an architect you have no other option. I always used to see earlier generation people as perfectionists (old school), There is every probability that my team is thinking the same way about me and your team about you.

Expect that you will make a lot of mistakes, forgive yourselves

The life of a software architect as a long and rapid succession suboptimal design decisions  taken – Philip Krutchen

And live to guide the aspiring architects, make a difference.

Happy Architecting, And do not  pee on the electric fence, read the books, learn the concepts, observe practicing architects / tech leads / lead programmers.