One year of experience many times
It is easy to become a victim of monotony at an organization with well established processes where all software projects move in a similar cycle. This is especially true in government, non-R&D, and non-startup organizations. Further, once an architect becomes comfortable with a given technology or a set of tools he or she may be unwilling to consider alternative approaches to solving a slightly different problem. For example, if a software architect just finished designing a complex system using the Model-View-Controller (MVC) architectural pattern with a team of experienced software engineers, he or she may automatically select the same approach for a subsequent system. But what if the subsequent system is simpler and is staffed with software engineers freshly out of college who are unable to quickly pickup more complex patterns? What if the subsequent system needs to be more loosely coupled and the Presentation-Abstraction-Control (PAC) architectural pattern is more suitable? The architect should take a step back not only to reflect on a recently designed project, but also to allocate enough time to take on the next problem from a fresh perspective.
It takes effort and discipline to make time to evaluate the past experience and learn from it. It is especially hard when an architect is not provided an opportunity by the management to reflect on the lessons learned. Architects who worked on the projects that were painful (unreasonable deadlines, poor management, lack of resources or training, etc.) are more likely to reflect on how things should have been different. It’s true that working on a project in distress, with no chance for success, can be a good learning experience, but only as long as one vows to remember the mistakes of the past so that they are not repeated in the future.
- Firebrand Architect on duty: CK
0 Comments:
Post a Comment
<< Home