In the ThoughtWorks project that I have been working on, there are just one lead and several developers. Even though the lead is normally called "Architect" because that is the term that we use externally, he or she is much difference from what people normally think of Architects.
Rather than drawing all kinds of fancy diagrams and leave to the developers to implement the design (More than once I have heard of this theory that the developers don't have to be highly skilled as long as they do what is told).
In my previous projects, I have been very impressed with the work of our project lead. Highly technical and very experienced, the lead pairs with the team and working out the design decisions with the team. I felt that this is the best way for each member of the team to learn and grow and this is the best way to come to the right decision for the project.
On this project, being an architect turns out to be much more than just leading the development work. The current project involves three different servers posting their interfaces through WebServices and communicate to each other through these interfaces. WebMethods is the data exchange platform so that more services can be added, and there is a CA server for certificate verifications. Because of this, there are a lot of coordination required among the development groups. In addition, the requirement is not clear so I need to help the BA on the story list creation.
So between the development groups technical discussions and requirements gathering, I have not been too active on programming. The worst day was last Tuesday, where I had meeting back to back from the morning to the evening. I have been trying to play catch-up, looking through the code after work. But now I realize that with the code changes everyday, I will end up killing myself and still not able to keep myself up-to-date. So I am now delegating the design decisions to the team and pay more attention to their development practices like pair programming, test driven development, rotation, etc.
The good thing is that with the BA on track with the requirements gathering and story list creation, I get to concentrate more and more on the development.
Subscribe to:
Post Comments (Atom)
2 comments:
"Rather than drawing all kinds of fancy diagrams and leave to the developers to implement the design (More than once I have heard of this theory that the developers don't have to be highly skilled as long as they do what is told)."
I agree completely with the idea that an architect is not someone who can diagram nice UML that they then hand over to the lowly developers to implement. I've seen this model too many times before and generally the architect hasn't done any significant coding in years. The architect ends up talking down to the lowly code monkey developers about how they don't understand how to implement their beautiful design. My rule is if you can't at least code examples of what you're trying to impose, you can't expect someone to implement it.
Interesting....I've seen lead dev's drawn to this situation before, and I've been there - done that as well. So often the role of lead involves masses of admanistrivia (administration and management). Highly skilled and highly communicative teams are less reliant on leads and can succeed fairly well without one. Indeed two roles can emerge, a management facing lead, and a more hands on developer facing lead. Making this distinction explicit can be important when development becomes dysfunctional due to a management facing lead.
Being one who strives to code before manage, I certainly prefer to be the latter type of lead, so I need plenty of assurance that a lead role will involve a majority of time coding.
Indeed, I also believe that the days of whiteboard architects are numbered, but as a management facing lead you risk becoming the thing you despise.
Post a Comment