When I started software development, I was amazed by software architects. I really was. Back then, I was taught that management was the best possible evolution career-wise. Since I didn't want to quit as a developer and abandon coding, I figured that architecture was an admirable goal for me. It would certainly take years and years, a lot of experience, in different contexts. I would probably have to master all the design patterns, have the SysAdmin and DBA knowledge combined in order to have the power to choose the right tool. After all, as they say
The right tool for the right job
Now that I'm more experienced, I look at architects differently. There is not one type of architect. Every company has their meaning behind the word architect. In most cases an architect is someone with a software developer background who does not code anymore, whether it be an enterprise architect, a solution architect or an application architect
No more coding?
Wait a minute ... the reason I decided not to go into management is that I wanted to continue coding. If architecture means no coding, then that's not really what I want.
Fortunately, and to avoid any misunderstanding, architects who code do exist. Fact is, most architects I've encountered do not code anymore. And as with any craft, as practice makes perfect, non-practice is catastrophic. I've seen some tasks assigned to architects, because they
are in an ivory tower have more experience. The architect had to do a proof of concept using a specific tool. I had spotted a GitHub repository to use as a starter. Turns out after several weeks, the architect demoed the same GitHub repository. Needless to say that I was disappointed.
To architect or not to architect?
I'm aware that there are coding architects, but I really want to avoid the amalgam with the non-coding ones. This is why I want to stay a software developer.
A software developer does not wait for an architect to do architecture
That is why I try to stay away from the title of architect due to this connotation.
If not an architect, what then?
Architect as a role makes me think of the difference between leadership and management.
Leadership is about being part of the team and getting involved, whereas management is about getting it done by the team. Well, an architect (who doesn't code) is similar to a manager who orders to get things done his way but never applies his own directives personally.
This is why I've decided to become a software developer with a leadership role. In other words a Lead Developer.
What's the difference?
This might seem pedantic, but as a leader, I take a different approach to communicating with other developers. Since I'm part of the team, my goal is to instill better practices and make sure that the team progresses. Ideally, the team is able to get along on its own after some time. Best yet, the team is able to challenge the architecture. When this happens, it means that the team understood the architecture and made it its own. Best yet is that the team thinks about the architectural impacts all the times. As well, it now becomes a collegial decision, which we all know from Agile methodologies to be better.
Don't take it personally
If you are an architect, you might think I'm criticizing your status, but I'm not. I'm only against architects who do not get their hands dirty in real code. As I said, every company has a different meaning for the role of an architect. I find that a real architect should be a full-time part of the team and help the team grow. In this case, the term lead software developer is more appropriate.
What is architecture?
For many, architecture is drawing UML diagrams, choosing tools and dealing with server provisioning and firewalls. That's probably the dullest part of computer engineering (to me at least). In fact, UML diagrams written by architects are rarely implemented at all. And that's not a bad thing. It means that software developers didn't follow the UML diagram blindly and thought about the best possible architecture as they were building the software.
The same goes for server provisioning and firewall. With cloud computing, provisioning has evolved a lot from network requests as Word documents to Infrastructure As A Service (IAAS) describe with code.
Tools are probably the last thing to choose as they convey limitations and complexity right from the start when developers should be focused on assimilating the domain requirement and complexity rather than struggling with an inappropriate framework.
So why do we burden with such preliminary documents when we all know that they are pretty much subject to change?
Coding is architecture
When building a house, the blueprints are made by the architect and executed by construction workers. I personally think this does not apply to coding. The blueprints of coding are the source code, and the construction worker is the compiler, resulting in an executable binary.
The architect is the software developer.
Every software developer should take part in the software's architecture. No design should be made without getting down in the code to get a concrete experience of the design decisions from the trenches.