Tuesday, May 20, 2008
Enterprise Architecture: Reviews should be constructive and not caustic
Yesterday, I was joking with a peer of mines about my sometimes suboptimal behavior in moving noise to others instead of shutting it down. Us enterprisey architects spend a lot of time during our day reviewing the work of others and therefore it is important that we all focus on making reviews constructive...
Whenever an Enterprise Architect reviews the work of others, it is guaranteed that it will become intimidating and generally unpleasant. The key though is to not make it unproductive. The purpose of a review is to make things better and this doesn't happen when folks hijack discussions for educational purposes.
If you are reviewing an architecture, the goal of the review is to increase the potential for success in the creation of high quality valuable working software. The purpose however is not to demonstrate superior design/coding/powerpoint skills. The funny thing about code reviews is that reviewers need to come prepared to learn and get off their enterprisey pedestal. Even experts can learn from newbies. Aside from producing better working software, one fantastic side effect of review is knowledge transfer and getting to see a problem and its solution from another perspective.
Please don't get it twisted and think that code reviews are about knowledge transfer. Focus on them being a side effect and not the main driver. One of the enterprise antipatterns is if you think of review as a learning activity, it gives far too many people an excuse to attend and more importantly, they will attend and be unprepared which guarantees that the value of the review decreases.
Enterprises have also indoctrinated themselves via constant CMMi brainwashing that reviews are for fixing things. They are not. Reviews are for measuring how good or bad something is. AS a small side effect, obvious things are pointed out and fixed. In general, the review of something after it has been produced tends to be too late to fix things if they are really wrong...
| | View blog reactionsWhenever an Enterprise Architect reviews the work of others, it is guaranteed that it will become intimidating and generally unpleasant. The key though is to not make it unproductive. The purpose of a review is to make things better and this doesn't happen when folks hijack discussions for educational purposes.
If you are reviewing an architecture, the goal of the review is to increase the potential for success in the creation of high quality valuable working software. The purpose however is not to demonstrate superior design/coding/powerpoint skills. The funny thing about code reviews is that reviewers need to come prepared to learn and get off their enterprisey pedestal. Even experts can learn from newbies. Aside from producing better working software, one fantastic side effect of review is knowledge transfer and getting to see a problem and its solution from another perspective.
Please don't get it twisted and think that code reviews are about knowledge transfer. Focus on them being a side effect and not the main driver. One of the enterprise antipatterns is if you think of review as a learning activity, it gives far too many people an excuse to attend and more importantly, they will attend and be unprepared which guarantees that the value of the review decreases.
Enterprises have also indoctrinated themselves via constant CMMi brainwashing that reviews are for fixing things. They are not. Reviews are for measuring how good or bad something is. AS a small side effect, obvious things are pointed out and fixed. In general, the review of something after it has been produced tends to be too late to fix things if they are really wrong...
