Blog

Write code or step aside

07 Oct, 2010

Most IT careers start with a programming job: you write code in one of the popular programming languages as part of a team. As your experience grows you start to get bored with software: you’ve been working with more or less the same technology and tool set for a couple of years and you need something new to keep yourself going. That’s the point where you have several options like becoming a project manager, coach, analyst or middleware expert. This story is about another option: becoming an architect.

At first, being an architect is relatively easy. Using the skills you gained while becoming a successful developer you can easily help others in a team of developers to be successful as well. You know what works and what doesn’t because you’ve solved similar problems on a similar platform. Because you’re more experienced you can be the natural leader of the team, the interface to the business owner and other stakeholders. Managing the teams’ environment becomes your job because you can explain complex technology and team dynamics to non-technical people. You coast along and leave the drudgery of coding to other people.
Excellent.
Time goes by and you get involved in projects you didn’t write any code for. You look at the technology stack used and you realize they’re using this new fangled TechnologyX. You read the tutorial on the Internet and you think ‘OK, I understand, TechnologyX solves ProblemY, great’. Next time a customer asks you for a solution to ProblemY you tell them the story of this other project where they used TechnologyX. You’re no expert yourself, but you’ve got a colleague who knows all about it. Next problem, please!
In the mean time, in a parallel universe you know nothing about, people start using other technology that also solves ProblemY in radically different ways but since you didn’t stumble on these things you just don’t know. You’ve lost the ability to learn something radically new. You are stuck. Your waistline grows and you have become waste.
I strongly believe there is only one way to grow your professional skills and to keep increasing your value for your customers. You have to continue learning new technology. Not just by reading about it but by experiencing new technology and new techniques first hand.
The process goes like this:

  1. Watch the presentation on InfoQ so you can sift out the obviously useless stuff.
  2. Read more on technology that passes the filter above so you know to what kind of problems it might be applied.
  3. Download the code for technology that might be useful for the problem you are working on or expect to be working on in the near future.
  4. Use the new stuff to solve a problem you’ve solved before so you can focus on the technology instead of the business problem at hand (if you feel really un-inspired you can just build yet another PetStore).
  5. Apply the new technology to a real life problem in a real project with real developers and a real deadline.
  6. Repeat from step 1.

The crucial step in the list above is step 5: without real-life experience and especially without a deadline you will never find out if it works. In particular, you will never find out where technology hurts and where it facilitates. Architecture happens in development teams.
This only leaves one final step: share your knowledge with your peers in other projects so your organization learns. And never ever forget step 5.

Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
guest
20 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback

[…] This post was mentioned on Twitter by olamy, Jawher Moussa. Jawher Moussa said: Dead on (regarding architects): Write code or step aside | Xebia Blog http://t.co/vCKo4TO […]

Sander
Sander
11 years ago

Strong piece Jan, and I agree as long as the architect is a software or project architect. To evade discussions on what those titles entail, I will not give a definition 😉 However, as organizations grow, the need arises for the “enterprise architect”, a guy or girl that has the eagle-eye view of the whole IT landscape. The question is: should he or she also keep programming? Or is his or her task more about leadership and communication in order to keep stakeholders happy?

Andrew Phillips
Andrew Phillips
11 years ago

> And never ever forget step 5.
How about “never ever forget step 6”? 😉 Also: how much time do you reckon should be invested in this continual learning process? Is this “architect’s homework” or something that should be addressed as part of a learning and training (time) budget..?

Viktor Grgic
11 years ago

Jan,
Well said! Although I do wonder what you think about enterprise scale questions. It seems to me impossible to try everything out before advising the customer.

Mark Bakker
11 years ago

Hi Jan, I agree with you, but besides the architects I also beleave this is also the same for the Middleware expert and so on. At some point in time technolgy is changing and knowing this as soon as possible is important. Still being an active developer will help for sure!

Erwin van der Koogh
11 years ago

@Viktor,
I think it is even more necessary to know the products/processes you are advising to your clients (whether they are internal or not) because the decisions made at that level have so much more impact. As an enterprise architect you should not be concerned with the release notes of the last release candidate for some obscure framework used somewhere in your organization. But you should know the ins and outs of an Event Driven Architecture before selling it to your organization.
We have all experienced ivory tower enterprise architects and the only way to stay out of that tower yourself is to keep your knowledge up to date.
Where I disagree is that the architect is the one who should be omnipotent. I have not coded in years, but I still consider myself a good architect because I surround myself with knowledgable people, understand the concepts and most importantly, leave most of the decisions to the implementing teams.
This combines both my experience with their knowledge and experience and makes for the best decisions.

trackback

[…] This post was mentioned on Twitter by EnterpriseArchitects, EArecruitment, EApeople, Trevor Snaith, EA Training and others. EA Training said: Write code or step aside http://bit.ly/9XVNyV […]

Iwein Fuld
11 years ago

I really like your view. I’d even go as far as to avoid the discussion of what the role of an architect is entirely. There are two types of people in a healthy organisation: builders and businessmen. Some builders understand architecture, some not so much (unfortunately).
Essential here is that businessmen should not be allowed to meddle with architecture.

kodeninja
kodeninja
11 years ago

@Erwin – “I have not coded in years…”
and you don’t miss that :)!?! I mean, with so many interesting technologies popping up every now and then, don’t you feel tempted to give them a spin. There seems to be so much innovation happening in the mobile space, web space etc. These are EXCITING times to be a developer! I think even Enterprise Architects should be doing Code Katas regularly, if nothing else!

Romin Irani
Romin Irani
11 years ago

A timely article that describes precisely what happens when one is not willing to learn new technologies or has not used it in a real project. However, the challenge for the architect is also to keep himself updated and hands-on continually because the pace of development and alternative solutions are so many. That is why I liked the last point where it is important to share the knowledge across — which can go a long way for everyone to learn.
Thanks for the article.

Sid
Sid
11 years ago

It is clear that this is entirely a developer’s “technology-focused” viewpoint and will be well received by developers, while conveniently disregarding the business, organizational, contextual & technical challenges facing the Architect because of his/her “Business-IT alignment” focus/responsibility. However, the amount of time & effort required to focus on “implementation/coding” aspects is extremely limited due to the fact that an Architect’s time is best utilized solving the myriad problems that lie outside of the coding realm. No amount of code is useful unless it is applied for building the right solutions in the right business context within the numerous constraints.
Once developers can stop obsessing about the latest & greatest language/algo/fad/whatever, and peek outside the cubicle walls of their little kindgom, will they realize that everything is done for adding value to the business.
Leader such as Architects need to play (if needed) a multi-disciplinary role by working across the entire spectrum of responsibilities such as Enterprise Architect, Project Manager/Scrum Master, Business Analyst, Technical Lead, Developer, etc.
Architects should leverage the deep technical implementation/coding skills of a developer by engaging him/her to solicit feedback for a specific use of a specific technology. Maybe the developer can help execute a small Proof of Concept by working with Architect. Engaging & extracting value from the right resource(s) is another quality of a good Architect.
In the meantime, developers can ignore the above and choose to continue obsessing and keeping themselves busy with a new technology/toy and somehow believe that the technology matters more than the problem context and the business needs. They will never grow to be Architects.

Erwin van der Koogh
11 years ago

@kodeninja
I completely agree that these are exciting times to live in, but after about 13 years of coding my interests have somewhat shifted. Much of my time these days is spend building teams and steering them in the right direction.
And while I do not spend a lot of my time coding myself, I am surrounded by my Xebia coworkers that breathe new technology.
@Sid
While Jan might have taken a slightly exaggerated standpoint in the discussion, yours is as well. An architect is a person that is able to translate the requirements from all the different stakeholders and translate that into a technical vision.
That does require you to not only understand those different stakeholders, but also have a deep technical understanding to make sure you can come up with with a proper vision.
Focus only on the problem context and the business needs and you will grow to be an architect. One of those ivory tower architects that can only draw boxes on a powerpoint presentation and that can’t really answer any of the relevant question that do arise.
While you do not have to have all the answers to all the questions, you do need enough technical know-how to have a proper vision. The developers themselves can fill in the rest.

Sid
Sid
11 years ago

@Erwin I totally agree with your views and personally as an Enterprise/Solutions Architect most of my time gets diverted into carrying out tasks for 3 different projects and future state strategy work at the same time. For example, in order to set the Enterprise Integration & SOA architecture & product selection, I am personally writing code (using Spring, Apache Camel, AMQP, etc.) for building the sample integration scenarios.
I just feel that there is a lot more diligence required to code a solid app that can only be taken to completion by a good developer. Standing aside because an Architect does not write the code till the end is not a reasonable expectation.

Erwin van der Koogh
11 years ago

@Sid,
I do not think Jan meant to suggest that an architect should be coding significant amounts of code that is going in production. And I certainly wouldn’t suggest it.
What I feel is important is that you keep up to date with the technologies that are around and are familiar enough with them to make good recommendations.

Laurent
11 years ago

I recommend reading S. Dreyfus and H. Dreyfus, A five-stage model of the mental activities involved in direct skill acquisition, 1980, http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA084551&Location=U2&doc=GetTRDoc.pdf

Uwe
Uwe
11 years ago

I absolutely agree with Sid. the post is actually talking about something like a “technical consultant”, not about an “architect”. Being an architect is something completely different than the stuff described in the post (see Sids explanation).
The problem I (sadly) see very, very often is very well shown by the post: Many developers seem to be unable (or unwilling) to switch perspective. They are only able (or willing) to look at everything from a developers perspective. As a consequence, they do not see the myriad of things outside their developers world that are a lot more important to companies success than the “new technologyX”. And thus an architect is limited to something like a “technology expert” in their perception.
As a consequence they do not only deprive themselves from a lot of opportunities with respect to their own value (as perceived by the non-developing rest of the company) but they also spread a lot of misinformation around that creates a lot of damage. For instance, in many companies “architects” are only considered being technology nerds … also because of misinformation like in this post.
And that is very bad for the companies because architects are needed more than ever … not for bduf … not for telling developers what to do … but for helping to create solutions that fit their purpose with respect to _all_ stakeholder parties and supporting to minimise costs across the applications lifecycles with respect to _all_ cost factors … and that’s something completely different than being a technology expert.
So, please, _please_ do not confuse lead developers or technical consultants with architects. Again, that’s something completely different.
For closing a bit more placably: One thing is true: Architects should code whenever they can to keep their work grounded … and because it’s fun, too 😉 … unfortunately they often do not get as much time for this as they would like to have.

Erwin van der Koogh
11 years ago

@Uwe
I think we are actually pretty much in complete agreement. I especially liked your term ‘grounded’. That is exactly what you should be as an architect. And that is sadly what is missing from a lot of career architects that haven’t actually looked at code for years.
Great discussion 🙂

Explore related posts