One year of experience many times

While at the Carnegie Mellon University pursuing a Masters degree in IT - Software Engineering one of my professors said: “You can have 20 years of experience or you can have one year of experience twenty 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.

It is easy to repeat the mistakes of the past, complain during the process, and then do nothing about it at the end. That’s how one acquires 1 year of (painful) experience twenty times. An architect is likely to reflect on the past experience if it was not a pleasant one (e.g. a failed project), so it takes effort and discipline to learn from the mistakes on the mediocre project or to see ways to improve from a successful project.

- Firebrand Architect on duty: CK

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement