Sunday, April 20, 2008
#
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.
Saturday, April 19, 2008
#
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.
Wednesday, April 16, 2008
#
For those of you (like me!) that were unaware of it, Microsoft has released a CTP of Rosario (the next version of Visual Studio). Jeff Beehler (lead program manager on VSTS)
blogged about this release a while ago.
I attended the Rosario Architecture Edition preview yesterday. Frankly, I'm two orders of magnitude more excited about this than I am about anything else I've seen here at the summit yet.
This past week, I came across an interesting piece of irony. I just left a job as a "software developer" where I was running Team Suite, and had access to the architecture edition of VSTS. At my new job as "software architect" they gave me developer edition.
So, I went to the Microsoft web site and downloaded the 30+ page document that details the differences between versions. (<rant> Come on, you guys! This used to be one web page that was easy to peruse at a high level. Do I really need to scan over 30 pages just so I can find out there's no real reason to upgrade to the Architect SKU?!?!??! </rant>)
Anyhow, summing up that one... VSTS Architect currently has
no compelling reason to buy it. Distributed Systems Diagrams just aren't enough of a reason to step up.
On the other hand.... Rosario is a compelling argument to step up. Yesterday, Cameron Skinner showed some of the features of Rosario Team Arch. The core of the story is a set of incredibly powerful tools for discovering the actual architecture of existing code, to design new architectures, and to link physical implementation to logical design features.
I can't praise these features as highly as I'd like to, partly because I'm a little hesitant to talk too much about the fine details about the demo. However, Cameron was able to discover dependencies and coupling between classes in a code base that is several orders of magnitude larger than anything I expect to be working on any time soon.
Seriously.... take the time to check this out. The download is huge, but if you're an architect accustomed to using Visio to diagram your architecture, you'll love these tools. They're still in beta, but you'll never look back.
Monday, April 14, 2008
#
As of 10 April, I've joined the architect team at
Colorado CustomWare.
This is a big change for me. A much bigger company, focused entirely on software. A team environment with lots of process in place and support structures in place. Lots and lots more interesting differences, but I only managed to get two days in the new office before heading out to Seattle... so there will be lots more interesting paradigm shifts to come.
Got to start yesterday with the VB Insider's get-together.
Then went from there to Party with Palermo.
Played pool with an Israeli C# MVP (Justin).... during which he made a comment about karma. Had to laugh... of all things I expected from this week, a conversation with an Israeli in a bar about karma wasn't on the list.
And I'm sure that won't be my only surprise this week...
Yes, I know this is old news by now.
I got renewed 1 April for another year as an MVP. Yes, I'm one of the April Fools' Day MVPs. (And this year, Microsoft let me sweat for several hours before letting me know that I had been renewed.)
This week, I'm at the MVP summit for the first time. Seventeen hundred MVPs here this year, from all over the world. Very well run, and the quality of the people -- both the MVPs and the MIcrosoft employees -- is even more impressive than I expected.
Of course, the Seattle weather is typical for this time of year -- rainy and cloudy. And it looks like it will stay that way the whole time I'm here... both for the MVP summit and the AltDotNet conference.
Yes, that's right... I get to stay for the AltDotNet conference. Gonna be a great week.
Wednesday, March 19, 2008
#
I forgot to mention my favorite quote from Alan Cooper's keynote today: "Building software is like walking through a minefield. It's really quick as long as you don't step on a mine."
At last year's developer summit, I was quite impressed by the quality of the keynote speaker. This year's speaker was Alan Cooper, author of "About Face" and "The Inmates Are Running the Asylum." He had quite a few interesting things to say, although not all of them I agree with.
Much of the material in the talk was lifted from books by Peter Drucker and Paul Glen ("Leading Geeks"). The talk was interesting, and at least a little controversial -- especially considering that I was sitting between two agile advocates.
Some of the interesting thoughts:
- software is replacing people as the primary point of contact with your business; the UI you present is analogous to the body language, stance, attitude of the people that used to be client-facing (Cooper)
- software now touches all aspects of business; therefore software management is now more important strategically than finance, manufacturing, shipping, etc (which Cooper now suggests are essentially hygienic)
- the true worth of a corporation is held in off-balance-sheet assets... the "people, technology, information, processes, corporate culture, brand recognition, management capability..." (Drucker)
- "The critical feature of a knowledge workforce is that its workers are not labor, they are capital. And what is decisive in the performance of capital is not its cost, but its productivity." (Drucker)
- geeks create a meritocratic subculture, based solely on technical skill, which they will value above all else; "The top geek commands influence and respect, not power" (Paul Glen)
- conventional management structures, with manager who understand neither geeks nor the challenges they face, force geeks to lie to management to keep them happy (Cooper)
- "developers" can be divided into interaction designers (what to build), design engineers (how to build it), and production engineers (built it on time, according to plan); each group is motivated differently, and should have separate career paths (Cooper)