Home > Architecture / Engineering > The Passage from Developer to Architect

The Passage from Developer to Architect

April 28, 2010
Following on from previous post of articles taken from ‘design patterns for .net’
 
The below topics relate to software architecture, the passage between a developer to an Architect and the debate of should a software Architect continue to code – however, coming from an engineering background as well as development to a minor extent, I see lots of parallels so you could equally read Engineer for Developer in these posts.
 

The Passage from Developer to Architect (by Rob Daigneau – design patterns for .net) – Read for full article, extract below.

Those who have been software developers for any length of time are probably familiar with the fabled crossroads where we must choose between a managerial path and a technical one. There is yet another crossroads we might encounter. When we are asked to play the role of architect, we must choose whether or not we will act as a "pure architect" who focuses on the world of abstract ideas, or if we will also continue to code (i.e. become a developer/architect). The compulsion to pitch in and help with the programming effort can indeed be strong. Most developers who want to be architects or think of themselves as such probably love coding, as do I, and leaving your love is hard. But if your goal is to become a professional architect, especially the enterprise species of architect, then you might have to consider leaving your beloved behind, at least in the workplace.

Yet Another Lesson from Star Trek

Remember the old Star Trek with Captain Kirk and Mr. Spock? If you’ve seen the series, then I’m sure you recall that every time a new planet was to be explored, the away team would always be comprised of the senior most officers including the Captain and the Chief Technical Officer. I always found this humorous. Anyway, in an episode called "The Deadly Years", the senior officers of the Enterprise (i.e. Kirk, Spock, McCoy, Scotty) are stricken with a mysterious illness that ages them rapidly and renders them incompetent. And if that weren’t bad enough, our heroes find themselves under attack by the terrible Romulans. Too bad for everyone, the leaders never taught their crew to run the ship on their own, or to become leaders themselves. They had no ability to function as a team and save themselves until McCoy found an antidote to the sickness, cured the Captain, and Kirk stepped up to save the day once again!

It’s a fun and dramatic if not a cheesy little story, but it’s also a parable for architects. Captains of starships and architects on projects are leaders, and leadership entails certain responsibilities. Amongst these are the requirement to provide goals to a team, ensure that the team understands the mission, stays on track towards that goal, and learns to function as a cohesive unit with less and less direction over time. The fact that the crew couldn’t function without the Captain was, in my humble opinion, a sign of very poor leadership. Kirk didn’t have a crew! He was the crew!

Architects who code are like starship captains that can’t delegate (uh, give up) dangerous planet explorations to their crew. You might love that job, but you might also find yourself marooned (in the code) while your ship meanders off into space. When you continuously move to the "front line" to code, your leadership takes a back seat.

Coding Limits Your Bandwidth

Just as captains of starships are accountable for more than are their crew, architects are accountable for more than are the developers on their teams. Rather than focusing on lines of code, routines, classes, and so forth, the architect’s calling is to attend to broader concerns. These include ensuring that the chosen technologies and technical designs achieve the business objectives, and that they do so within the given budgetary, schedule, and resource constraints. The architect’s responsibility rises from working on individual .Net assemblies, web forms, and web services, to planning for how all these things will collaborate to attain the goals of the company. As an architect, you’ll probably be thinking more about how different subsystems will integrate to produce products, than how to optimize certain blocks of code within those products. Architects can not possibly accomplish all of these things when they spend significant portions of time programming. Giving in to these urges only limits the scope of what they can do on a larger scale.

The architect must therefore let others do the coding while helping them stay on course. This is only possible if the architect provides a clear destination for the team to navigate towards. It’s certainly not easy letting go of the oars, but when you do, you’ll find that you’ll be able to take the helm, and by doing so will have a greater ability to handle a larger scope of concerns.

If you do find yourself jumping into the code, not only do you risk antagonizing the developers who may feel you’ve intruded in on their turf, but you might also be hurting their professional development.  This oftentimes occurs when impatient architects finds their developers or database engineers struggling with a problem that they know how to quickly fix. If the architect consistently comes to their aid in such a situation, they won’t learn. Instead, we need to let our teams make mistakes because this tends to enforce true learning. Remember that architects are responsible for more, and this greater responsibility typically includes the career development of others. 

What’s Happening to Me?

As your attention rises to bigger picture concerns, you will probably not be able to stay up with the ongoing changes to the languages, frameworks, and tools. This transition in one’s technical career can be quite disconcerting, and most feel that pull back to software development. You should consider resisting this pull in the workplace, and must accept the fact that you will not be the top-coder anymore. Because of this, it is wise to acknowledge to others when you don’t know something, and defer to their more current knowledge when appropriate. Don’t pretend to be the expert when you’re not.

You’ll probably find yourself attending more meetings than you did as a developer. I still recall on former teams when we used to joke saying that there were those who did actual work (i.e. the developers), and there were those who went to meetings. If you become an architect, you’ll be going to a lot of meetings, and will have become one of "them".

You’ll also have to deal with that dreaded word … politics! Everyone says they hate politics, but let’s face it. Where ever there are people, politics can be found. Architects need not fall prey to the "dark side" of politics (i.e. the idea that politics are always negative and are primarily concerned with the manipulation of people for your own benefit). Instead, architects should seek to work for mutual benefit, consensus, and compromise. You will certainly need empathy, negotiation, and facilitation skills in order to properly serve as an advocate for both the development and business teams, both of whom are your constituents. If the thought of these things turn your stomach, then maybe architecture isn’t for you. If, however, you take a chance, you may find that working through problems with people can be quite rewarding both professionally and personally!

The Passage

The passage from developer to architect can be scary and confusing. You may find yourself being “drawn to the light” of software development, and you must choose whether to go towards it or to take a different path. If you do follow that other path, you’ll find that the challenges and activities of the new role definitely make up for your forfeiture of programming. Remember, you can always keep your chops up by developing a web site as a hobby in your copious free time at home J

Advertisements
%d bloggers like this: