Jeremy Miller pointed out the corollary to my comment that "good developers move to good companies." In order to attract good people, become a good company. What that company looks like is a matter of debate. It would be rather an interesting debate, too -- a true insight into what developers, on the whole value in a company. As with many other interesting discussions, there will be a set of answers that is as varied as the people themselves.
Personally, at this point in time, I'd take a quick stab at it by saying that it's a company whose management clearly defines the end goal, and gets out of the way while the technical team accomplishes that goal. This is, perhaps crudely stated, but it's roughly approximate. Surely, it reflects the struggles I had with my last company -- my perception that management didn't understand enterprise software development and wasn't willing to make the investments to work in that space. (Of course, I may be the one who really doesn't understand the problems and is naively assuming that quality could be improved by the introduction of unit tests, for example.
This isn't to suggest that management has no role in the development process. I'll readily admit that I can get lost in the effort to define a clean, extensible, scalable architecture while very little "useful" work gets done. However, as I move into this new role, this new job, I find myself wondering if anyone whose day-to-day job function is primarily non-technical should be involved in fine-grained technical decisions.
(I'm going to include many architects in this category, since they don't code any more, being instead primarily concerned with higher-level issues such as organizational behaviors, politics, infrastructure and ... well, the architecture. At some point, I'd say many architects start moving to a more management-oriented role, particularly in large corporations.)
I've been reading Fred Brooks'
Mythical Man Month. Not just the essay, but the
collection of essays. At one point, Brooks defines the architecture as "... the complete and specification of the user interface." I can't bring myself to believe that Brooks is agreeing here with Alan Cooper, that the "interaction designer" should be the one designing the entire system, and everything else is merely an implementation detail to be handed off to a team of "production engineers" to implement. Perhaps this is merely my personal bias speaking.
However, it seems to me that any modern definition of a software architect, systems architect or enterprise architect would require that individual to be a technical expert across multiple areas. The primary job description of a modern architect seems to be more of making technology decisions, to provide an infrastructure for the success (or failure) of a project.
Is part of the reason for the continual, massive failure of technology projects the failure of the modern architect to properly document the system they have conceived? Is it instead that we document at too detailed a level, overly constraining the experts in a specific technology by being too specific about implementation details? Or is it that we've lost a broader focus on usability, simplicity and elegance?
Or is it that times have changed, and Brooks' implementers were more of a
master craftsman, intimately familiar with the nuances of the hardware, of the compiler, of the software language? After all, these were the wizards that programmed on punch-cards, masters of esoteric dark arts that today's developers have had abstracted out from under them. Was being a
guru more the norm in Brooks' era?
Somehow, I resist this notion. True, we now have phalanxes of developers, many operating far below the master craftsman level. Does this imply that an architect must be a master of all technologies, knowing fine implementation details? The very term "architect" conjures up the analogous individual in the building world. The most renowned examples of building architects are individuals who blend vision with art and engineering expertise, pushing modern materials to their limits. To be sure, sometimes these visionaries have caused the implementers incredibly interesting problems to be solved. But, the visionary architect is hopefully backed by a visionary team of master craftsmen, and the astounding happens.
(I'm recalling a Discovery Channel documentary about the building of a technical research facility in the hills overlooking a town that hasn't changed much in the past few hundred years. The architect envisioned a faithful reproduction of the topography and layout of the town below. Hundreds of glass panels, some huge, all hand-cut faced some buildings. Other had concrete facings that were so steep that conventional concrete wouldn't stick to the wall.)
One comment that was made in the ALT.NET session on how software engineering fails was (I think) made by Phil Haack, who said that we, as developers, "are professional problem solvers." Indeed, very few of us would be interested in developing software if the problems were easy. How many times have I railed against having to write or maintain trivial, plumbing code? That stuff can be written by anyone, and I'm really not interested in doing it.
The real challenge ahead is encapsulating the lessons learned from overcoming the interesting, difficult problems, disseminating them into the broader community, and enriching the art of software development.
Since I just posted that last comment, and saw his name at the bottom of my blog in the development credits, I thought I'd just mention that I got to meet
Phil Haack at the ALT .NET conference this morning, right after the session discussing the challenges of software engineering.
We spoke briefly about the suitability of our names -- how he can't help but be a hack, and how all the men on my dad's side of the family are opinionated.
Nice guy. Oh... and the technical discussion preceding it was good too. I need some time to wrap my head around that one, however, before I post anything about it.
I really like the core comment made by Jeremy Miller
here. Really, this is similar in flavor to the comment that Alan Cooper borrowed from Drucker. (Summary: good people are worth the cost.)
Good developers tend to migrate to good shops. JP Boodhoo phrased it well. Many good developers eventually get to the point where they realize the truism "if you can't change the place where you work, change the place you work."
I came to this realization several months ago. I was tired of being told things would change, but having no support when I tried to make those changes. I eventually came to the conclusion that I didn't have the energy to effect change throughout an entire organization that had no understanding of software development.
I don't claim to have that great understanding. If I thought I did, the past week (MVP summit plus the ALT .NET conference) would have cured me of any such delusions of grandeur. But, at the end of the day, I have to agree with Jeremy -- there is a core of software development fundamentals that transcend language, but are essential for the professional developer to understand.
The challenge is to instill this understanding in the average developer... and it's the responsibility of the "alpha geeks," as community leaders, to attempt to convey this knowledge to their peers. And you don't have to be an "alpha geek" to get out there and learn.