I read a post at Fast Company called "The Value of Rough Seas." There is a quote in there which got me thinking about whether we really have to participate in some really rough projects to advance in our confidence, skills, and credibility.
"A smooth sea never made a skilled mariner." -- English Proverb
Certainly, being on a rough project is like combat sometimes and just surviving the experience is a real boost to our confidence on the next project.
However, do we learn just as much when we are lucky enough to be on a project where the leadership is truly competent and the big panic that we brag about surviving was avoided completely? Is there a temptation on some people to enjoy the adrenaline rush of the pressure cooker project a little too much?
As I think about it, we probably gain a lot more visibility on the pressure cooker projects. The pressure certainly helps us remember what NOT to do or what part of a project estimate NOT to short change. I probably makes us better reviewers of other people's designs and other people's estimates.
In some sense, these are really more like project management and risk mitigation skills. And.. these are not necessarily the first skills that come to mind when doing word association with the phrase "I/T Archtiect."
I suspect we might actually learn about the technical aspects of one architectural decision over another in the relative calm of a saner project schedule that allows for some give and take between mentor and protogee.
I guess it depends on the critical success factors of the project. If the delivery date is all that matters to the client, they won't be too impressed with all the extra flexibility you built in which dragged out the date.
But all of this is part of the "art" of being an I/T Architect I think. We have to learn how to judge what the real criteria for success are. True success may not hinge on architectural elegance... though it might be more fun if it was. We have to judge what we have to do to be "done" and declare victory.
Another way of looking at it is the whole tactical vs. strategic struggle. We often want to pursue the really elegant, strategic solution. We often have very tactical clients. In this case, we have to balance how much elegance we have time to work into the tactical solution.
The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.