This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: A Tale of Two Architects
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Arnon's recent post on Pair Architecting raises several intersting points. Paul also mentions this in his post: Becoming an Architect. I think that the pair-architecting I'm involved in these days makes both me and Arnon more effective by fracturing the Architect role into two roles: The Software Architect and The Product Architect. In fact, this is just what the project needs.
The first: The Architect as a Coach.
I'm beginning to see that there is really no other way. You can only do so many design and code reviews. Eventually, you have to contract the scope of your conversation to that which the developer is dealing with, and grow that scope outwards until they understand the larger implications of the decisions they make with each line of code they write. I think that this can only be done in pair-programming sessions, as equals. Laying down the law from above doesn't work. You need more than just buy-in, you need understanding. In fact, you need the developer to give up their ego and come consult you on various thoughts they've been having about a given design. This can only occur if you give up your ego first.
I've seen what happens to projects when the architect is viewed as someone above/outside the team that actually is accountable for bringing the project to completion on time, budget, and scope.
Another point raised is the "refactoring" I'm doing on the client-side software. AKA, tearing it apart, rearranging it, and stabilizing it. If we hadn't waited so long, there might have been a chance to "de-clutter the code" (Rachel Davies style). This is after a total re-write of one of our services which contains nearly all of the business logic (for this version).
The fact is that these two points are tied together. It's all about education and bringing up the collective ability of the team.
Previous Topic
