Write code or step aside

Jan Vermeir

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.

Comments (20)

  1. [...] 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 [...]

  2. Sander - Reply

    October 8, 2010 at 8:39 am

    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?

  3. Andrew Phillips - Reply

    October 8, 2010 at 9:45 am

    > 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..?

  4. Viktor Grgic - Reply

    October 8, 2010 at 9:46 am

    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.

  5. Jan Vermeir - Reply

    October 8, 2010 at 11:11 am

    If architecture is a 'emerging property' of what happens in projects, then some coordination is needed, much like a scrum-of-scrums. If you don't spread knowledge and experience and set some boundaries on what is allowed you will harvest chaos.
    Actually I think Xebia's model to share knowledge in our company may be an excellent way to avoid chaos without getting in the way of progress. In a larger enterprise I would organize, facilitate and promote knowledge sharing by having projects present their architecture and coding experience (especially that) with others. Code kata's should be an essential part of regular meetings to explore new stuff.
    The enterprise architect is in my opinion a person who facilitates knowledge sharing. Being a technology visionary helps but I don't think that is necessary. After all, if you manage to harness the brain power of all developers in your organization, why would you need a visionary?

  6. Mark Bakker - Reply

    October 8, 2010 at 12:29 pm

    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!

  7. Erwin van der Koogh - Reply

    October 8, 2010 at 12:39 pm

    @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.

  8. [...] 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 [...]

  9. Iwein Fuld - Reply

    October 11, 2010 at 10:22 am

    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.

  10. kodeninja - Reply

    October 11, 2010 at 10:32 am

    @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!

  11. Romin Irani - Reply

    October 11, 2010 at 1:29 pm

    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.

  12. Sid - Reply

    October 11, 2010 at 2:41 pm

    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.

  13. Erwin van der Koogh - Reply

    October 12, 2010 at 3:30 pm

    @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.

  14. Sid - Reply

    October 13, 2010 at 6:39 am

    @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.

  15. Erwin van der Koogh - Reply

    October 13, 2010 at 7:04 am

    @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.

  16. Laurent - Reply

    October 13, 2010 at 8:26 am

    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

  17. Uwe - Reply

    October 13, 2010 at 10:09 pm

    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.

  18. Erwin van der Koogh - Reply

    October 14, 2010 at 8:51 am

    @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 πŸ™‚

  19. Jan Vermeir - Reply

    October 14, 2010 at 7:36 pm

    In my opinion architecture is a property of software that needs to be developed as the software grows. It can be bounded by constraints laid down by the organization the development team is working for. In the Dutch IT industry an IT architect writes no code but functions as an interface between business and IT. I think this is the job Uwe is referring to (hope I understood that correctly). While this might be a useful concept in large enterprises, it is also a huge pitfall it is easy to stumble into.
    My first problem with this job description is that architecture becomes a constraint that easily turns into a non-breakable law stifling all innovation. Even worse, if architecture is somebody else's problem, why would I bother as a developer? Why would I care getting it right? Or even innovate?
    The second problem is that a proxy between a development team and a group of stakeholders sounds attractive at first glance but keeps the team isolated from the people who supply the requirements. Why do we need a proxy here, or anywhere else in your organization for that matter?
    Finally, some of you argue that as an architect you can try new technology. This sounds nice but I don't see how that is going to help if the technology is not applied to a business problem. You will never find out if something works without a real deadline. Therefore you will have to try new stuff in the context of a project and then you might as well be part of the development team.
    We need consensus, peer reviews, open discussions about technology and architecture but all this can be done without a person with architect as a job title. So as a replacement for a person or an office I propose a culture that encourages knowledge sharing.

  20. [...] [VIA] [...]

Add a Comment