I found this post today via the DDJ Portal: (http://www.ddj.com/blog/architectblog/archives/2006/04/should_architec.html?cid=GS_blog_arnon)
My position is that architects MUST code in order to fully understand what they are asking the team to do. In fact, the architect must be engaged as a developer on the team he is ‘architecting’ for (Damn, I hate verbing nouns).
As far as being tasked with explaining various design decisions – usually explanations of delays or alterations to the schedule to those who pay the bills; hey, that’s why they pay us better than ‘regular’ developers.
We are expected to know what we are doing, and yet be able to explain the concepts and the benefits of particular decisions to people who want applications, but don’t necessarily have the technical skills that we do.
In my experience, architects who don’t code construct unrealistic models and constraints.
By-the-way, I am not aware of an agile methodology that advocates the splintering of anyone’s attention to the project. Here’s a quote from the article:
“On small projects, it might be possible for a person to take two roles; for instance, work under the architect role as well as code in a developer role. However, in such cases it would probably be more beneficial for the company to get the architect to work on more projects and share their expertise, rather than limiting their contribution to a single project.”
One of the main points of agile processes is focus. Focus is what makes it work. Diffusion of focus – being involved in many projects – is anathema to the ideals of agile methodologies.
One of the biggest challenges I’ve faced as an agile coach and architect/developer is to get the client to commit a team to a single project rather than having them responding to emergency support calls mid standup.
I recently left a project on the west coast where we’d managed to maintain a steady team of four developers for about six months and progress was great. To put it in the words of the client’s manager, “The developers are happy, the clients are happy; What’s wrong with that?” or words to that effect.
A week after I departed, I contacted a colleague to see how the project was progressing. He said, ‘This guy’s leaving, and that guy has been reassigned to something else. The remaining guys are being asked to work on other projects simultaneously.”
It’s the single best way to hobble a project. The last two team members are the newest to the team/process. They are good developers, but they are going to be forced back into the multi-project, low focus mold.
Too bad. There was such promise for that project as another example of why agile processes are better than waterfall.
I’m off to a new project after a brief trip to Las Vegas for the Microsoft Mobile and Embedded Windows DevCon 2006. If you like gadgets like I do, you’d think it was a cool place to spend a week too.