This is an often-asked question that has views on both side. Those in favour will argue:

To design a system for coders you must understand how to code (and be coding)

You can't design a system without being aware of what is happening at ground level

Architecture is not just about broad stroke design but about adapting to changing needs at the code level

on the other hand,

Architecture is a high-level role and should be not be concerned about implementation details

Coding is a detailed oriented, heads-down funtion which is at odds with the risk management, broad view nature of architecture

Architecture is about technical risk management and not implementation

Architecture is about leadership. It's difficult to lead from behind

In my experience architects should not be spending a lot of time coding but must keep in touch with the code base primarily through lead developer communication, review and stand ups. If you spend a lot of time coding you lose sight of the high level issues and become ineffective at managing technical risk.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

What are the "high level issues" that coding blocks a person from seeing?
–
harley.333Oct 17 '08 at 14:18

22 Answers
22

Even if your argument against coding is valid, I think it's important for the dev team to respect you and your design decisions. If you "suffer the consequences" of your architecture decisions right along with them, then they're much less likely to question them.

All the time, I see architects who are out of touch with the coding side, and whose dev teams know it. They don't get much respect.

I agree that respect is important but being an effective technnical risk manager is equally important especially from the clients perspective. If you spend to much time in the engine room you can't steer the ship.
–
Richard DormanOct 17 '08 at 14:29

2

@Richard Dorman, great analogy! I see what you mean, to add, I think being a better Architect is about balancing both sides of the coin. You need to manage risk and delegate, but you need to prove why you ARE the architect. It's sort of Machiavellian.
–
Zachary YatesOct 17 '08 at 17:23

I agree with Zachary; it's a balance, of course. You simply have to show that 1) you have enough confidence in your design to be willing to code it yourself and 2) you still know enough about programming to not create a design that is detached from reality
–
Lucas OmanOct 17 '08 at 19:26

I believe there are several types of architect, each in their own domain:

business and functional architects: they are concern with business operations and functions workflow, and they actually should not ever code, because they have to be able to abstract themselves from any kind of implementation, and they must produce functional specifications which leave the technical solution open.

applicative architects: they divide a functional domain (like "profit and losses analysis") into applications (like "portfolio processor", "launcher", "dispatcher", "gui"). They do not need to code, but they should be former coder in order to have a clear idea of technical challenges that their architectures must address. Their primary skill is not coding though, but listening to technical colleagues in order to choose the right solution. They will then produce technical implementation which must be implemented (coded).

technical architects: they are in charge of choosing and/or implementing technical frameworks (those which are generic for any functional project, like KPI, logging, exception management), and they should absolutely code (and code well), since their components will be used by all the other functional teams.

development architects (hey, that's me ;) ): in charge of development tools and processes, and technological surveys, they should code and love coding as well.

So I believe there is not just one answer: it depends on your architectural field and expertise: when it comes to 'application architects', I believe the three latter categories can have different coding experience...

Interesting: I know about infrastructure architect (and they may code, especially php web site for monitoring their architecture!) and I am not familiar with "solution" architect... Why do you not post your vision in a separate question ? ;)
–
VonCOct 17 '08 at 15:01

I think the role of architecture is changing. I see less and less ivory tower architects that design a whole system for the lowly programmers to implement in a waterfall process.

When doing iterative projects communication between architects and programmers gets more important. The architect is part of a team and should be able to handle changing requirements and new ideas together with the programmers. In situations like this the job of an architect and a programmer are more closely related. I've seen teams where the dev-leads took on the role of architects deliver well thought out architectures for really complicated solutions.

edit In reply to comment
I think in the distinction between application, solution and enterprise architect is a bit artificial and doesn't really fit in many cases. Roles like security architect, data architect etc. give a far clearer disinction between responsibilities. You can look here for more details http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

By the way, from reading your question again I noticed that many of the arguments against coding architects seem to indicate a strong management/leadership role for the architect. I think it's a good idea to separate the management and architecture roles. It's better to have your technical people divide their time between coding and architecture than between management and architecture.

Is it worth making the distintions between application, solution and enterprise architect in this context?
–
Richard DormanOct 17 '08 at 14:16

1

@Richard Dorman, maybe it's not worth making the distinction for this question, but it definitely makes sense to distinguish for the broader question of 'What can I do to be a more effective architect?'
–
Zachary YatesOct 17 '08 at 17:26

Yes. Software architects who haven't written code for years lose touch with the realities of building a product. They start producing grand designs with ever-higher levels of abstraction, which seem to keep slipping their ship dates.

Every project I've worked on that has included an architect that did not spend a significant portion of their time hands on with the code has had problems because of that absence of hands-on knowledge.

That includes the projects where I was that architect :-)

It's now a personal big red flag.

I agree with all the arguments in favour of architects who code. The arguments against don't hang together well for me.

The code needs to abstract the high-level concepts as well as the low in an application. Unless the design and code are integrated at all levels the solution is going to be less than optimal.

As for "Coding is a detailed oriented, heads-down funtion which is at odds with the risk management, broad view nature of architecture" - in my experience a broad view - and risk management especially - make for better coders not worse :-)

"Architecture is about technical risk management and not implementation" - not it isn't. It's about risk management and implementation (and a bunch of other stuff).

"Architecture is about leadership. It's difficult to lead from behind" - why does coding put you behind? Personally I find that the best place to lead is with the people you're working with.

+1 - You make some good points. I do think that there are business or product specialists who can serve as leaders on a project but who do not (and can not) code. However, the best of all worlds is where someone has the experience, intellectual flexibility and communication skills to do all levels
–
Mark BrittinghamApr 12 '09 at 0:10

There is an argument that architecture has nothing to do with coding and is almost entirely about risk management. I have seen at least one project where the architect had no exposure to the code base at all. All the design was done in UML. The project wasn't a success!
–
Richard DormanOct 17 '08 at 14:14

Probably it was not successfull because of a lack of coding experience among the architects. I think a good architect also needs to be a good coder.
–
grigyOct 17 '08 at 21:28

There are architects and there are IT strategists. If you are leading an integration project involving 500 people across multiple departments then no, it's going to get in the way. If you are leading the design and implementation of up to a few 10s of people on a development project, then yes. Otherwise you will be far less likely to have the appropriate insight into the day to day reality of working with your architecture.

I don't think that they need to be coding everything in the application. But they should be given some tasks. Some "architects" are basically hacks with no technical experience who pass themselves off as "legendary coders" and design systems that add weeks or months to the amount of work you would have had to do if you didn't have an architecture. If they can't write code they have no business being in that role...Because the idea is an architecture should make the application easier to develop and maintain. But if the architect cannot develop, how would he or she know how to make an architecture?

Also, even the best architects make bad decisions. Sometimes something looks great on the white board but then in reality an architectural decision ends up making things a lot harder than they should be. If the architect has to eat his/her own dogfood (and use the architecture) they are more inclined to want to correct bad decisions or to architect ways around them. Also by touching the code they are at least a little familiar with it. So if a developer comes to them with a coding issue, the architect's eyes won't glaze over as he/she dismisses the developer and says the developer is doing it wrong but offers no insight onto the right way to do it.

The architect doesn't need to be doing big projects within the code base. But they should at least be doing small tasks within the code base that force them to use their own architecture. Also the small tasks will probably involve reading a lot of other people's code to give them a sense for how people are using the architecture and whether anything can be done to improve it.

Only those that decide to prototype...Plus this way they can see how the architecture is actually being used. And either teach developers the "right" way or see that his/her way was not realistic.
–
CervoOct 17 '08 at 17:10

As Vlion stated, asking this question in a community overwhelmingly dominated by developers means the answers will be skewed towards "yes".

As somebody who has "architect" in his job title but who was also recently awarded the badge of "Distinguished Engineer", my loyalties are torn. In general, I think coding is not usually an effective use of an architect's time. So what should I be doing?

Understanding the business.

Understanding the systems used to enable the business.

Working with the business on IT strategy and tactics.

Making sure current projects are being done with a long-term view, where the project manager concentrates on the short-term view.

So how should an architect keep in touch with reality? I think by regular meetings and walkarounds, just talking to people at every level and oiling the wheels of communication.

I've come to believe that, more often than not, "implementation details" are not details (in the sense that many problems arise when you consider some specific implementation problems as mere details that could be disregarded as minutiae from an "architectural" perspective)

An application architect must be able to define an application architecture, design the application, implement the patterns and coach other to code. If you can't do those things then you are not an application architect.

Would just writing the interfaces count as code? If so, then this is the minimum I'd expect from an architect, while in other cases it may be much more code from them such as classes with stubs for methods.

Architecture is a core skill for software developers. There may be a few rare occasions when it might make sense for an architect not to code, but I can't recall ever encountering such occasions in my own experience.

The architect must either code on the project or at a bare minimum, be fully capable of coding on the project. The second part of this means that they have to be able to code using the tools and techniques being used by the rest of the team. (Without continuing to code, it must be very difficult to maintain these skills.)

Finally, when architects are responsible for choosing the tools and techniques to be used by others, they can not make such a choice well without actually using the proposed tools. In this scenario, the non-coding architect rapidly degenerates into a pointy-haired-boss with a pile of brochures on his desk.

I wonder why nobody has mentioned the code reviews or pair programming which can replace coding.

I spend much more time reading the code and solving problems with my coworkers than coding. This give me almost the same understanding of the code, its structure and complexity as writing it myself and is much less time consuming. When I code, I do that for fun or to explore new technologies (This is the only place where I've found coding useful).

Architecture is a high-level role and should be not be concerned about implementation >details

The code is the design. Imagine an architech who designs pretty buildings but refuse to go into implementation details like where to put the mergency exits, plumbing, electricity, elevators or builiding legal issues.

* Coding is a detailed oriented, heads-down funtion which is at odds

with the risk management, broad view
nature of architecture

When you code, at first, focus on the details. Then you refactor with a broader focus.

Architecture is about leadership. It's difficult to lead from behind

The battle front of software development is coding. May be the product manager or the project manager does not code. But the architect needs to do it. May be he should spend more time refactoring showing how good can code be. This way he leads by example.

On a large scale application, it may not be possible for an architect to stay updated with the code being written. Also, it would not be possible for him to write the code because of other important responsibilities. Having said that, I would recommend, the architect should not loose the big picture about the code base being developed. This can be achieved by monitoring the code base for code coverage, metrics about code quality, static code analysis, etc. He should regularly assess the code quality using the mentioned criteria. The practices of 'continuous integration' can help here.

This standard Developers answer is that an Architect should also be coding. But it's a kind of Developer that puts technology first. But I tend to disagree. Yes it's beneficial to have some coding skills, in order to be able to review the code.

But the only thing an Architect does is bring together the business requirements with the implementation. And in our case the code. If you have a seriously complex system, you cannot be coding and doing Architecture at the same time, cause you're operating at too many different abstraction levels.

Instead you should be able to rely on the Developers. They should be able to describe the aspects of the implementation, and how it fits in the business requirement that you have pointed out to them. What technology is chosen is the Architects decision, but to come to that decision he has to do research or use past experience. That doesn't mean he doesn't talk to the Developers, or let them investigate a specific technology to see whether the Architecture really works.