Sitting on a flight from Dallas/Fort-Worth to Orlando for Gartner’s Orlando Portals, Content, and Collaboration Summit, I just observed an event that reminded me of why I believe so strongly that architects ought to cut code themselves. We’re being redirected around the leading edges of a storm line stretching from southwestern Arkansas all the way down to Houston. I am lucky enough to be riding my frequent flier status to an upgrade at the front of the bus, while coach is filled with already-exhausted parents and screaming kids excited to spend “quality time” with the Rat. Yeah, I am pretty happy to be up here.

Anyway, the row in front of me is filled with a familial unit, including 2 kids. I love kids (especially my 2 boys). But more to the point: I love kids who behave themselves. And for the most part these kids behave (if only due to their mobile electronic distraction units). That probably shouldn’t surprise anyone – if you’re in business class as an 8-10 year old kid, it’s because your parents are either very well-off financially, or because one or both parents work in a field demanding a lot of travel, and upgrades were made. In the latter case, these kids are probably still pretty well-off. Children of financially secure parents tend to be children of well-educated, well-behaved parents. Maybe not fair, but there it is.

Because we are being diverted around a storm system, we are enjoying a bit of a bumpy ride. The pilots have turned on the fasten seat belt sign, made announcements about the importance of remaining in your seat with the belt fastened, and our flight attendants have reinforced these ideas. When the plane is rocking side to side, the pilot is telling you to stay in your seat, and your friendly flight attendant is doing the same thing, you should probably stay in your seat.

So, back to my in-flight neighbors. Well-behaved in general, they don’t know how to follow the simple request to stay in their seats for their own safety. It is patently obvious why they don’t “get it” – their parents don’t get it either; they get up and use the bathroom, change seats, and so on, generally serving as a bad example of how to behave yourself as an air traveler. Kids parrot their parents. Fortunately, in the case of in-flight turbulence, most of the time nobody gets hurt, even if they can’t follow rules.

How does this relate to your role as an architect? Well, line programmers parrot you the way that kids parrot their parents. If the rules don’t apply to you, they won’t be taken seriously by the people you’re to nurture and develop. If you act like coding is a big imposition, gifted yet ambitious developers will aspire to a role where coding no longer matters. If you don’t experiment, create prototypes, and research new technologies, you certainly won’t engender interest in same from your programmers. Unfortunately, most of the time, someone or some project will get hurt by such behavior.

I don’t mean to draw an unfair comparison between developers and children (although in some rare cases, such a pure comparison is appropriate). What I mean to say is that everybody needs to be led. In your organization, architects probably don’t lead people in a traditional hierarchical sense – but architects certainly lead by example. How you conduct yourself matters. Choose to spend some of your time coding, even if you believe it isn’t the most valuable use of your time in a pure business sense. In terms of the example and inspiration you supply your organization’s line developers, it matters a lot.

Thoughts on Leading by Example – Architects Should Code

There may be occasions where your argument has some merit but your argument is a thin one.

Actual programming is 10% or less of the task of most projects and that 10% should be performed by full-time programmers who know the programming components intimately from a coding perspective. In other words, programmers should code and they should do so based on company conventions, programming practice, and their own skills.

Whether or not an architect codes is irrelevant. That’s not our jobs – otherwise we’d be called programmers/developers or whatnot. This is not to say that Architects *can’t or shouldn’t* code, this is just to say that its not a requirement of the job.

Now, when you’re speaking to behavior, this is a separate issue. In today’s economy there is far too much ruthless back-stabbing, disrespect, and absence of professionalism in corporate work. that’s a function of poor pay, parts-is-parts outsourcing mentalities, and a corporate culture driven by rabid, Hollywood reality shows that emphasize jungle themes as models for corporate behavior.

Architecture is a corporate niche that is different from programming. To mix this up is no sin but to believe Architects are somehow authorized to set corporate cultural tones is just wrong.

Architects usually get the job by being great communicators in addition to being great programmers. Your point that Architect job descriptions often don’t require programming is valid.

Just because it’s not in your job description doesn’t mean you shouldn’t do it. I disagree that Architects are not “authorized” to set corporate cultural tones. Leaders set the cultural tone for the organization. Yes, it starts from the top down; that doesn’t mean you have no responsibility as a leader yourself.

Eric,
I like your concept of leading by doing. I think it also implies that coding is a building block skill that should be possessed by higher level responsibilities, such as being an Architect. That may be debatable, but I like the notion, having cut code myself for many years. Professionals generally have more respect for a leader who has done their jobs and walked in their shoes. There are many stories about the “incompitent boss” and no one wants to be that, and I do think retaining relevancy in development skills is a good practice for an Architect. I do agree.

About

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.