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.