I catch myself correcting people all the time when these terms are used because not many seem to use them correctly, at least correctly by my judgment. I am going to speak my mind here, and put out into the public eye, what I think the difference is between each of these roles.
I say roles because they are not people. They can be people, they most certainly are almost always jobs within a company, but at the lowest level they are roles. Each of these is a pattern that a person has to fit into to serve that particular purpose. Multiple people can fill each of them at once, just like one person can fill several, but at any one given time a person fits into either one of them. Because of a persons experience and knowledge levels, as well as their underlying personality, they may be qualified to fill one of these roles or they may not. They may be good at one or not.
I am going to start by putting out a very crude diagram to show my personal view (perhaps rash generalization based upon my experience) of how these roles fit within a development hierarchy.
The first thing you will notice is that architects are on top and programmers are on the bottom with developers nicely placed in between. This is not out of any disrespect for either developers or programmers, but we must be honest with ourselves, there is a certain level of expectation between these roles that places them within a very specific hierarchy. Like it or not, professionally speaking, one step up and better than the lower. I use ‘better’ as a relative term here to mean more experienced, more accepting of responsibility, and shouldering more expectations. I know that sometimes programmers can feel the entire weight of the project on their shoulders, but in reality, if they are then someone above them in the hierarchy is not performing in their role properly.
So, how do I place these roles within this hierarchy? What criteria do I use? How do I measure the expectations?
Architect
This person(s) is responsible for the technical footprint of the solution. When it comes down to understanding how all the various piece-parts talk to each other, this person knows. When it comes down to understanding the difference between a clustered and a load-balanced set of servers, this person knows. When it comes down to understanding why clustering is better than load-balancing within the context of the enterprises architecture, this person knows. When it comes to understanding how a specific messaging architecture fits in the system, this person gets it. When it comes to understanding why it may be better to use a server with multiple physical CPUs vs. one with multiple processing cores, this is the guy to ask.
Can they do the work of everyone below them? About 80-90% of it, yes. Should they be responsible for doing low-level work within their project? I don’t think so. Why? Because for a really technical person that has to work at the implementation level it is very difficult to shift gears to a high level technical view and stay objective, to not select one method over another strictly on the merits of its contribution to the overall business need instead of what may be simpler, or cooler, to implement. If an architect is going to be required to actually do work on a project at a lower level then I don’t think it should be on their project. If they are going to switch gears then I think it should be a clean switch.
Architects have to not only be able to work at this high level, but they need to be happy working there. I have seen many cases where developers have been promoted to architect simply on merits such as length of service or their great ability to lead a team of developers and programmers, but be miserable wrecks when they reach the level of an architect because they miss the thrill of the compile. They need to be able to feel personal fulfillment by the act of a project coming together more than the rush of seeing a passing unit test. They need to be well with the fact that they made a good decision on what message transport they selected rather than feeling the high of spending all day working with WSDL and message versioning. They need to feel comfortable sitting in an ivory tower once in a while, even if those bellow them feel a bit off because of the view..
Developer
Developers are the top of the ‘do-er’ list. These people do the work. The build the systems designed by the architects and understand the low-level implementation details of HOW to build the stuff that was designed. You want to know the various methods available on an object? This is who you ask. You want to know how large an XML message is as it goes across the wire between servers? This person can answer that. Do you want to know how two objects connect and what the ripple effect of a change is going to be? Ask these folks.
Developers know it all within their areas of expertise. And to be honest, developers need to maintain a specific area of expertise because software development changes so darn fast that you cannot possibly know it all to a high degree of efficiency and knowledge. You can be very knowledgeable in a ton of areas, but when it comes down to knowing how the bits move in a specific way you need to really have a core set of technologies that you are great in. These folks need to understand how tools like UML help them and how they can hinder. They need to know the difference between book theory and implementation reality. They need to know that ‘pattern’ is not a magic word unless it can really solve your problem, and that OOP is not a mandatory way of life, but you better think at least a little before you decide that it isn’t. This role also understands why you should need a note form your mother to use a global variable in development, but also understand that doing so does not make you an evil Satan worshiper. Developers understand the reason that code comments are useful and that not every line needs to be commented.
Some people can feel confused and worried living here because they think that they need to know it all at a very low level. I think these people are best to live at one level lower, as a programmer until they get a level head enough to move a level higher as an architect, and they may actually end up being very good architects given enough experience.
Programmer
Beginner, Script-kitty, copy-paste-developer, these are the first words that come to mind when I think of this moniker. Don’t get me wrong, being a programmer is part of the natural progression of becoming a developer, and then an architect. Most of us learned to crawl before we could walk, and learning to write software is no different. Programmers understand the syntax, but probably not the reason behind using different patterns. They understand the idea behind separation of concerns and multi-tier development, but are probably not completely clear on the subtle nuances that can make it work well or bring a system down around their knees. They can debug most of the code they write, but get itchy when they have to read others code, or work on code that was written years ago but someone else. They also may not view the process of design, review, and code as having much worth and feel more comfortable by just sitting down with their beverage of choice and writing code to hit a mark. These folks maybe great at writing glue, the code that binds the ‘stuff’ of a project together, but they have not yet had enough experience to be responsible for all the low level details of an objects overall implementation. They are, the good ones, hungry for knowledge and want to learn as much as they can, but focus until they get closer to being a developer they are in an endless search for the silver bullet, the best way, the one true method that allows them to work efficiently and write the next killer bit of code. These guys comment their code because they are told that comments are good but for the most part it is feast or famine. They either comment everything or nothing.
So there we go. If I make it sound like one role is better than the other as in architects are just better people than programmers are, then please accept my apologies as that was not my intention. I think every one of thee roles is very important for a well balanced development team. Like I have always said, the world needs both planners and doers if it wants to get anything done. If there was no one to put their head down and code then it does not matter how good the design is, nothing gets done. So, if you are a programmer that is learning and growing, and understands their role and plays well there, then I say congratulations to you for being a necessary cog in the system. If you are an architect and feel that I am giving programmers or developers too much credit for their jobs then shame on you and get out of the industry because your attitude is getting in the way. Everyone has to start somewhere, it's a natural progression that everyone should go through.