#sa4d Key Point: Architects should code

[Junilu Lacar]

I have gone through most of the book already and one of the many things that Simon says that really resonates with me is that architects should code. I absolutely agree with this.

The main character in Ayn Rand's "The Fountainhead," Howard Roark, is a great example of this kind of architect. For some reason, the one thing that has stuck with me over the years since I read that book is that Roark was the kind of architect who thought that it necessary that he spend a summer learning how to properly install rivets on the steel girders of a building because if he didn't know how to do that kind of thing right, how could he expect to design a whole building correctly? By the same token, architects who just draw up Visio diagrams and Word documents and do not spend time seeing their visions through to working code and "living" in the code with the developers are like the Wizard of Oz: They are far removed from the reality and, more often than not, the pain that their lofty ideas or perhaps the lack of understand of those ideas, inflicts on developers.

One comment I got recently when I suggested that our project architects should code was "That's ridiculous! We already don't have enough time for all the things we need to do, now you want us to code?" I think it's ironic because if you really analyze what these "architects" were so busy doing, it was really fighting fires that came out of misunderstanding the vision and structure of the system being developed. If they spent more time working with and collaborating with developers and testers, helping them understand the architectural vision and guiding them in making some key implementation decisions, they wouldn't have to worry about fighting fires so much. But it's a hard sell for these kinds of "architects" so I have little hope that they will ever get out of that vicious cycle.

My questions to the folks who are interested in this book are these:

Do you think architects should code? Why or why not?
What do you think separates an "architect" from a "developer" or is there really that much of a difference?
Would you agree that "architect" is a role, not a rank?

[Jayesh A Lalwani]

Do you think architects should code? Why or why not?

Yes, I'm a big fan of the application architect being the pathsetter. Don't just talk about what needs to be done; make a template that shows how things should be done, and then let other people take that template and multiply it a hundred times. I'm also a big fan of the architect being a tool builder. Don't just figure out how to do something; spend your time figuring out how to do the same thing better/easier/faster, Then build tools/frameworks around it that makes everyone's lives easier. The architect can build tools that generate code(or atleast prototype them). The architect can build/prototype tools that mine production logs for monitoring health

What do you think separates an "architect" from a "developer" or is there really that much of a difference?

I tend to think of the architectas the person(s) who are able to think about the system deeply. One of the important skills of an architect is being able to look at the same thing from differrent viewpoints. How does this application use hardware resources?How does it look from a security POV? How does it interoperate? How is the usability od the application? How do the users use the application? This allows the architect to figure out side effects. The architect should be able to say "Making change X will cause A to happen, which will cause B to happen, and hence instead of doing X, we should be doing Y", or "SOlution X affect system A and B in this manner, but solution Y affects C and D in that manner, and these are the tradeoffs". The architect thinks of the system more holistically.

Would you agree that "architect" is a role, not a rank?

I also think the architect-developer divide is not a divide but a continuum. You acquire architecture skills as you go along. There are developers who can think of the system at a much deeper level than other. So, to me, it is a role and a rank. TO an extent, the architecture and development is the responsibility of the entire team. The developer might be someone who spends most of his/her time coding and less time figuring out, and the architect might be someone who spends more time figuring out, and less time coding.

[Junilu Lacar]

Jayesh A Lalwani wrote:So, to me, it is a role and a rank.

I think I get where you're coming from. It's like how a black belt is a rank but true black belts command respect not from the color of the belt they wear but from the way they conduct themselves on and off the mat; it's how they demonstrate their skills with ease and humility, never hesitating to help those with lower ranks along their paths of learning. In that sense, being a black belt is really more of a role than a rank per se. Thanks for sharing that thought, Jayesh, I like it.

And to those asking questions about specifics of the #sa4d book, these are the kinds of things the book got me thinking about, more philosophical than technical really.

[Padmarag Lokhande]

One idea that I think can be borrowed from SOA is to provide Blueprints. This is like template where you don't just preach but provide something that can be taken as a reference or starting point. This fits to the concept of architectures coding as well.
Even if Architects do not do actual coding, they should be able to do so when required or to guide others.

Regards,
Padmarag

[Jayesh A Lalwani]

Junilu Lacar wrote:

Jayesh A Lalwani wrote:So, to me, it is a role and a rank.

I think I get where you're coming from. It's like how a black belt is a rank but true black belts command respect not from the color of the belt they wear but from the way they conduct themselves on and off the mat; it's how they demonstrate their skills with ease and humility, never hesitating to help those with lower ranks along their paths of learning. In that sense, being a black belt is really more of a role than a rank per se. Thanks for sharing that thought, Jayesh, I like it.

Oh man! you touched upon a pet subject of mine. Why Why Why? There goes my afternoon

! I'm a big fan of modeling agile teams as martial arts schools. Staying in our philosophical cloud for a bit, there is a big philosophical differrence between how traditional schools and university style of learning works. It used to be that the "teacher" used to be considered a guide. This was approached in differrent ways in differrent cultures. The best surviving example of this Eastern martial art schools/buddhist monastaries us of the belt ranking system above. This kind of system is much more effective is providing individualized training. The training that the student receives is tailored to his/her personality and growth. Also, not only do you learn a subject, you learn to teach the subject as you go along. However, this system is not good for "mass production". In software development terms, it doesn't "scale well". Now, at some point in time, this little thing called the industrial revolution came around, which resulted in an explosion in demand for skilled workers. THis is where the university style system started exploding. In the university style system, you have a handful of teacher,s and a "cohort" of 20-40-80 students. Each cohort learns the same thing. The teacher's primary job is to dump this skills/knowledge into the students head. The university/class kind of learning has tremendous economies of scale. You are basically creating a factory whose output is reasonably skilled workers. The bad thing about this system is that a) you are not growing the student as a person b) Clear deliniation of roles: tThe student is responsible for learning and the teacher is responsible for teaching, as a result the student never learns how to teach the subject

What has happenned over time is that we just fell into teaching software in an university/class based system. As a result, the students who come out of universities expect a clear divide between being a student and a teacher; and a clear deliniation between leader and follower. Here's the "lead" who will tell you what to do; here's the "architect" who will teach you new stuff and tell you what to do. You do what you are told to do, and learn as much as you can. No No No.. this is where we fail. This works when you need economies of scale. However, there are no economies of scale in software. We have known for (maybe) 30 years now, that adding developers to a project doesn't make the project go faster. We want developers to be problem solvers, not a bunch of automatons. We want small, highly focused teams. we don;t need a factory of software developers. Instead we want A-teams.

A martial art way of learning is much more applicable to a software dev organization. In a martial school, every person is a student as well as a teacher. You are responsible for teaching things to people below your rank. This acknowledges a little known trick that trying to teach something to someone makes you understand that thing you teach better, and also being an inquisitive and eager learner encourages your teacher to think about the subject deeply. The best way to learn is to teach, and the best way to teach is to learn. The grandmaster/Sensei/Architect in a martial arts school/software development team is not responsible for teaching individuals. S/he is responsible for making sure everyone is progressing, and structuring the classes/coding assignments in a way that everyone learns from each other.

[Padmarag Lokhande]

Excellent Jayesh!

[Bear Bibeault]

I absolutely agree. I always insist that I have feature responsibilities in addition to architectural duties because it's the only way to be grounded in reality. I've worked with too many ivory tower architects to think otherwise

[Simon Brown]

Bear Bibeault wrote:I've worked with too many ivory tower architects to think otherwise

I've actually been fairly lucky in that respect, in that most of the architects I've worked with have been excellent developers. There are a few exceptions though, including an architect who insisted in reviewing my J2EE code despite never having written a line of Java in his life. You can imagine how that made me feel!

[Jayesh A Lalwani]

Maybe he wanted to learn

[Jeanne Boyarsky]

I complete agree that architects should code. (and unit test - I wish that went without saying.) I consider pairing as coding from this perspective. On my previous project, I spent a lot of time pair programming with people on "their" tasks rather than picking tasks for myself. That way I'd be available to help with the harder stuff.

[Sai Hegde]

Well put, Jayesh.

[Simon Brown]

Jeanne Boyarsky wrote:(and unit test - I wish that went without saying.)

Me too.

[Kent Bull]

Jayesh A Lalwani wrote:

Junilu Lacar wrote:

Jayesh A Lalwani wrote:So, to me, it is a role and a rank.

Oh man! you touched upon a pet subject of mine. Why Why Why? There goes my afternoon

! I'm a big fan of modeling agile teams as martial arts schools. Staying in our philosophical cloud for a bit...

I am loving this discussion! I appreciate that people here on the ranch are so free and open with their thoughts. For a guy like me it is a godsend to have more experienced people talking about things like Software Architecting, design patterns, and project management. Why? Because those are the things I did not learn in school. After reading this discussion I finally realize what my position is. I thought I was a team lead, a project manager, and a software developer. Now I realize that the more correct qualification of my position is Software Architect and that I function as a project manager, a team lead, and a software developer. This helps me more clearly position myself in the overall scheme of things.

This discussion really motivates me want to develop my programming skills to a high degree. Since the manager directly above me does not yet have the vision of teaching me how to code then I wonder where I would go to find someone like a martial arts student would go to find a master. Would my best option be to switch companies or do we know of places online or otherwise that people like me can go to learn from masters?

Overall, this is a great discussion!

[Junilu Lacar]

Kent, if you go through the list of the people we have on staff here, you'll find that many are authors and most are highly experienced people who are eager to share and advise those who ask. As far as switching companies, that's a bit extreme if you're just looking for a mentor. Try looking around your company to see if you can get on a project with some good, experienced people first. Try to do more collaborative development on your current team. Pair programming with different people is a great way to expand your horizons and see things from different people's perspectives. It just might surprise you to discover new things about your teammates.

Going back to the martial arts analogy, I always welcome a chance to work with new people and folks with lower ranks than myself. Sometimes new or less experienced people can show you a new perspective on something that you've looked at in certain way for a long time. Sometimes I learn more from one session of working with less experienced folks that I do with other black belts. Open-mindedness and humility are great teachers.

[Jayesh A Lalwani]

I agree with Junilu, for the most part. The best way to learn is to teach, and there comes a point in your career that teaching is the most effective way to further your own studies. Abandon the student teacher dichotomy. Think of yourself as a student-teacher. You are a student as well as a teacher at the same time.

I would like to add one more thing though. How much you learn from other people is highly dependent on those people. So, it's better if you surround yourself with people that you want to learn from. They don't have to be smarter or more knowledgeable than you. However, there has to be a culture of free flow of information and ideas. If you find that you don't like most of the people around you, or you are unable to engage them, leave the job.

[Kent Bull]

Junilu and Jayesh,

thank you for your replies, I appreciate your comments. I do think that switching jobs would be extreme at this point. I expect I will have success if I start asking for someone to mentor me. This discussion has set in my mind that the ranch is one of the places I plan to go for advice and help.

[Simon Brown]

Kent, do you have any meetups/user groups in your area? If so, I'd certainly recommend heading along to these, particularly if they run coding dojo style sessions where you can pair with somebody else you practice your craft. If there are none, perhaps that's an opportunity.

[Kent Bull]

Simon,

as far as I know there is a JUG, an Oracle UG, and some other users groups. I haven't reached out to them yet. That sounds like a good opportunity for me. I appreciate the suggestion.