The role of architect
Thanks to a pointer from Kent Beck, I’ve just read Alan Keefer’s post, Taking Responsibility. This is probably the best description I’ve ever read of the role that a software or system architect should take.
And it’s very different from the role I’ve normally seen them take. Most software architects got the title because they were very good software developers. I’ve seen far to many who assume that they should now do the “highest level” of the work they’ve been doing, that of the system level design, and leave the more mundane work to those who are still software developers. In other words, they’re considering their promotion from the point of responsibilities they’re shedding rather than those that they’re taking on.Alan, instead, speaks of the enormous responsibility that he has with the role of architect. He says, “my job is to make sure that the project doesn’t fail for technical reasons.” There’s no refuge in saying, “I did my part right.” It all has to work.
This is an important point for all of us to consider, whether architect or not. It’s never very satisfying to hide behind the statement, “I did my work well, but those people over there screwed everything up.” We can all do better than that. We can all look around and see what else is going on. We can do things to help that larger picture. We can do things to adjust to the reality of that larger picture.
Of course, we can still fail. But when we fail, it’s a pathetic refuge to blame the failure on others if we made no attempt to succeed at more than the tasks right in front of us. And if we did try hard to help the project succeed as a whole, but it still failed, then must accept some responsibility for that failure.
“In spite of my best efforts, the project failed.” There is, in that statement, both a sense of failure and a sense of pride. “I gave my best efforts.” Perhaps they were not enough for these circumstances. Perhaps they were the wrong thing in these circumstances. We do well to reflect on what we did, why things happened the way they did, what we might have done differently, and what we might do in the future. Retrospecting as a team would be wonderful. Retrospecting by ourselves is something we can always do.
Now, go read Alan Keefer’s post, Taking Responsibility.