ALTDOTNET

What is an architect anyways?

Jeff Certain — Mon, 21 Apr 2008 04:51:24 GMT

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.

Meeting Phil Haack

Jeff Certain — Sun, 20 Apr 2008 19:15:22 GMT

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.

Who you calling an alpha geek?!

Jeff Certain — Sun, 20 Apr 2008 19:11:07 GMT

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.

Takeaways from ALT .NET Conference Seattle (Day 1)

Jeff Certain — Sat, 19 Apr 2008 21:23:02 GMT

Now that I'm a (woohoo!) bona-fide architect, in a shop that I'd categorize as agile (although I don't know enough to be able to say what flavor of agile we follow), I now have an interesting task ahead of me... taking meaningful lessons and concepts away from the ALT .NET conference and applying them to development in a team environment.

Everyone at CCI is, I think, convinced of the value of agile. They're doing some pretty interesting things, including having a bunch of subject matter experts (SMEs) on staff. Since we produce shrink-wrap products, the SMEs essentially act as our clients internally, giving direct feedback on the work the development team has done.

Now, the question is how leading-edge agile thoughts and techniques, such as mock objects, NHibernate for persistence, fluent interfaces, DSLs, and the like get rolled into this process.

ALT.NET Conference -- Day 2

Jeff Certain — Sun, 07 Oct 2007 15:23:14 GMT

I've got to say, I've been really impressed by the number and quality of the attendees from Microsoft -- Simon Guest, Howard Dierkin, Peter Provost, Scott Guthrie, Scott Hanselman... and I'm sure I missed others. These folks have been extremely willing to listen to feedback, and to give us a bit of insight into the workings of Microsoft.

Ironically enough, the room full of agile devs didn't know about the MS Agile Development Center.

ALT.NET Conference -- Microsoft MVC

Jeff Certain — Sun, 07 Oct 2007 14:49:17 GMT

There's no lack of blog entries about this.... but I'm going to add my two cents worth. Scott Guthrie spent about an hour demonstrating the new ASP.NET MVC project that should be released to the public.

This is one of the coolest technologies I've seen in a long time. The MVC project team designed based on a few very important principles -- separation of concerns, extensibility, and designed for testing.

Let me say this again.... Microsoft is working on a development tool that is designed for testability out of the box.

From the prototype that Scott demonstrated, Microsoft has this one right.

One of the other exciting features that stayed a little bit under the radar is this -- the MVC framework is intended to allow the developer to plug in whatever IOC and/or dependency injection package they want. Microsoft has (at least at this point) decided to allow the developer to use whatever tool they like, rather than having a prescriptive out-of-the-box solution to replace those solutions that already exist in the user community.

Look for the first beta drop in 6-8 weeks.

ALT.NET Conference -- Intro/Session 1

Jeff Certain — Sat, 06 Oct 2007 15:55:40 GMT

I've somehow found myself at a conference of agile practitioners in Austin, TX called ALT.NET. My main reason for attending this conference was a deep desire to explore what options exist for development processes. (Little did I know what I was going to be getting myself into...)

Scott Bellware had also received a tremendous response to his initial post describing the conference. I have to confess a certain selfishness in wanting to spend a weekend in a room full of people far brighter than myself. The three Scotts (Bellware, Hanselman and Guthrie), Martin Fowler, Roy Oshgerove, Jeremy Miller, and Jamie Cansfield are in attendance as well as, at a guess, 60+ bloggers from the technical community.

Interestingly enough, Microsoft was sent quite a number of employees -- some interesting names there as well, which may herald some change of mindset on their part.

Run on the Open Spaces concept, this conference is as much about building community as about learning technical skills -- perhaps more so. In some ways, this is a surreal experience for me. As such, there is as much learning done at the bar as in the sessions. Passionate and polarized conversations abound, amidst much laughter as well. (For the record, there is a reasonably large Canadian contingent here... and, yes, they did close the bar last night.)

Part of the Open Spaces comment is that we, the attendees, not only got to select the topics, but are also encouraged to move from room to room. I sat in on the start of a Ruby discussion -- hoping to understand the technology and why I should care about it. Luke Melia and Mike Moore led that conversation, a dialogue with many religious references to "conversion experiences." It seems that many disillusioned developers are shifting to Ruby because it provides a more intuitive programming model, and is intended to make a developer's life easier.

There's a lot of talk about using Ruby to address fundamental flaws in the implementation of object-oriented programming, such as the assertion that C#/VB.NET are class-oriented rather than object-oriented. Comments such as this make me curious about the shift in mentality required to really embrace Ruby throughout the industry.

But the main characteristic of the Ruby conversation was an ever-growing number of passionate people espousing the joys of Ruby, and attempting to educate those of us who were, as one gent put it, "Ruby newbies."

The conversation got slightly sidetracked, and I chose to wander to the room next-door, where a conversation about domain-specific languages (DSL). Talk about a surreal contrast. I opened the door, slipping in quietly.... to a silent room of developers who appeared, at first glance, to be in a prayerful or meditative state. It was a minute or more -- though it felt like an eternity -- before one person ventured a question. It turns out that I was in a roomful of the curious, who seemed at times, to not know enough to ask meaningful questions. Instead, we listened as Jeremy Miller, Scott Guthrie and Martin Fowler had a discussion, sitting on the outside, hoping to glean gems of wisdom.

What a profound contrast -- the energetic, evangelistic Rubyists just beside a room full of more academic contemplative developers attempting to wrap their minds around the challenges of DSP.