"Everyone wants to save the planet, but no one wants to help mom do the dishes"
We are increasing the failure rate of projects and decreasing quality of- and relevance of- software projects in America by the way we treat our top performers.
I have written in the past about what I feel is one of the greatest sicknesses in Corporate America - namely that businesses have an impendence mismatch between that which will actually help the organization meet its goals and that behavior which finds itself rewarded in the same organization. I haven't always put it so gently.
The Corporate Ladder, and the drive to climb it, is having a negative impact the profession of Software Architect. The Software Architect is in some ways falling victim to what I call Fry Cook Syndrome. In my late teens and early 20s, I was a fantastic burger flipper and all around food production prodigy. A point comes when the owner/manager can no longer justify further rewards to a lowly burger flipper and so I was promoted to Supervisor. The problem was, although I could make delicious burgers and a beautiful sundae I was not in possession of any leadership abilities. Sure, working hard and leading by example is a step in the right direction, but it won't turn a sarcastic college kid into a good leader. Furthermore, the business had lost a top producer in the attempt to reward him.
While I joke about Fry Cook Syndrome all the time this article isn't about Architects getting into something they aren't suited for. This is about the how the organization recognizes and rewards Producers. We have some groundwork to lay down before we tackle the core issue: Titles, Perspectives, and Recent History.
I once worked at a consulting company where for a long time we were able to pretty much choose our own titles. This led to one person calling themselves "Senior Internet Architect". Not to be outdone, the next person crowned themselves "Principal Architect", while a "Chief Enterprise Architect" won the day. I have even heard of someone who calls themselves a Galactic Architect; presumably the architectural needs of the Galaxy trump those of the mere Enterprise. Attaching nonsensical names to ourselves as part of an effort to be "More Architect-y" than the next Architect is clearly a sign of cultural sickness.
I was recently operating under the ostentatious title of Director of Solution Strategy. In a way, I'm at a crossroads where my current position would lead easily into a more management or Enterprise centric role on one hand and back into more solution architecture and technical leadership on the other. One thing that has repeatedly spilled out as I have meetings with interested parties is that I need to ship systems right now and I don't want to get further from directly solving problems. There is a process of turning requirements into code and fully participating in it means getting your hands dirty.
I was once working with a most excellent architect. He understood his particular business, was a great abstract thinker, could write code as good as anyone's, but he felt he had an issue with how he and his group were fitting into the organization. The high level architects, he claimed, needed to get away from "shepherding projects". I never forgot this statement for two reasons. For one, I thought that "shepherding projects" was a good way to put the leadership responsibilities of a good architect. For two, I thought "Well, what else should your team be doing day-in, day-out?" When did it become taboo for technical people with Computer Science degrees to write code?
In other words, who's going to help with the dishes?
The Evolution of the Architect in Corporate America
As of the time of this writing I've been programming in The Real World for about ten years. While I cannot personally say this with any degree of certainty, I see enough anecdotal evidence from talking to More Experienced folks that there was a time when the average software developer was more technical; back when there was a Computer Science degree but not an Information Systems degree, perhaps; back when everyone looking for programming work had done their share of pointer math and taken a compilers class or studied the Unix source code. As more and more businesses discovered the benefits of software systems, the demand for software developers grew faster than the supply. The supply did not show signs of increasing at a satisfactory rate for two reasons. The first reason was that a career in Computer Science or any core Engineering discipline was even less sexy in the recent past than today. It just does not attract people in large numbers and the culture seems to be especially abysmal at attracting women. The second reason is that compared to many other things Computer Science is hard for a lot of people. Hard coursework weeded out a percentage of the people who were otherwise interested in being a software developer.
While an answer to the first problem seems to require a massive cultural shift and may only take time, businesses and colleges conspired to create a partial solution to the latter issue. The Information Systems degree and its derivatives were born. In these degrees the math component was toned down a bit - most of the businesses did not require programmers with hard core knowledge of Calculus. The programming was toned down - you might still take C++ classes and write data structures from scratch but you wouldn't be studying compilers or Unix source code. Businesses soon began to write real systems in higher level languages, so soon C/C++ was considered optional as well.
Some people come out of these programs and thrive, some people demonstrate a career-long lack of polish stemming from lack of a true Computer Science background. Only some parts of a system really required this training - Parts like the high-level technical vision for large systems. The Architect of a system came to be known as the smartest guy in the room, needed to keep the simple proletariat developer in line...
I assert that for various reasons there are not enough high level technical people focusing on Solution Delivery because everyone wants to be An Architect who doesn't get their hands dirty in the lowly tasks of writing code or requirements. When I talk about people involved in Solution Delivery I mean the people who create the architecture for a solution, implement some of the use cases or modules, help other developers get things done. I'm talking about the people who go to requirements meetings to help the business, and come back to find a line of people looking for code-level help waiting at their workstation/cubicle/office. These people might be discussing the impact of frameworks on their project with the Galactic level Architects. These people are on the conference calls with partners. These people are often considered to have the best estimates, the most accurate perspective, the people you go to if you want to know how the project is really doing.
Companies large and small need people who can help get things done. As Joel recently wrote, this can often mean that writing code is the most valuable activity.
This might be a good time to re-read Philip Greenspun's ancient wisdom. A good software developer is often ten times more productive than a mediocre one. A good software developer who is capable of higher-order abstract thinking, with some leadership abilities, who is not oblivious to organizational politics will often rise to the level of Some Kind of Architect. Some times this is good, other times the company has just pulled a Fry Cook Operation and in the process hurt themselves and the entire profession.
Businesses are using career path and compensation to incent people to endeavor to become higher and higher level architects and avoid writing code.
The problem is that businesses don't understand the value of writing good code, the true value. The developers with a proper mindset of Software Engineering and Craftsmanship may very well be providing their highest value possible to a business when they are turning requirements into code. Too many managers view writing code as a low-value task, something that's just a stepping stone on the way on the way to something bigger. This ultimately leads to a culture where writing code becomes a "guilty pleasure". The organization goes about systematically promoting the best developers and the organization suffers for it. "What can I do?", a manager might wonder, "I can only pay a software developer $75,000 but the pay scale for Enterprise Architect goes up to $125,000."
Nonsensical constructs like this will quickly motivate people to do anything to attach the word "Architect", or "Architected" to themselves or their work. As Phil so rightly observed, great developers can often implement large systems or tremendous modules entirely on their own, but the organization fails to recognize this as an extremely valuable talent that ought to be rewarded.
Call to Action
None of this is to say that we don't need great Software Architects. Hell, I (like everyone else) consider myself a great Architect/Application Designer and sometimes those skills are just what's needed. Businesses big and small need to stop considering writing code a low-value activity. Software Developers need to have soft skills just like everyone else today. We need to recognize the value of great developers, we need to recognize that highly skilled developers with human skills who can also quickly turn requirements into code should be rewarded in proportion to the value they deliver and not because of an ostentatious title. We need to remember that it takes True Craftsmen to deliver great systems and that Craftsmen should not be second class citizens. We need to be sure that people can be successful without needing the title of Principal Inter-Galactic Senior Integration Architect.
Now, if you'll pardon me, I have some UML diagrams to finish.