Thursday, April 05, 2007
Enterprise Architecture and Code Review
Should enterprise architects have standards around code review?
It has been a long time since I have participated in a code review and lately I have felt the need to get back to it. Normally, when one becomes an enterprise architect they concern themselves with issues higher up the food chain. Lately though, with emerging security considerations such as PCI where secure coding practices are being discussed, I it feel like enterprise architects need to pay more attention to the details of technology and not solely focus on either strategy nor aligning with the business.
The funniest behavior is that many folks don't even know what a code review should feel like. In my belief, it is more than getting someone else to look at the code before it goes to production. That practice is not really a code review but more like a "commit" review or code approval.
Sadly, the notion of code review is fast disappearing from corporate America especially in shops that have outsourced to all those junior developers in India. Sure, their methodology and heavyweight processes in order to trick enterprises and their process weenie management that they are following best practices does the ceremony of code approval while the talent in the states is sadly waning as no one hear wants to write code and therefore also loose the skill to review.
Should enterprise architects ask themselves, how come code reviews don't happen in their shops. I suspect some of the reasons are:
| | View blog reactionsIt has been a long time since I have participated in a code review and lately I have felt the need to get back to it. Normally, when one becomes an enterprise architect they concern themselves with issues higher up the food chain. Lately though, with emerging security considerations such as PCI where secure coding practices are being discussed, I it feel like enterprise architects need to pay more attention to the details of technology and not solely focus on either strategy nor aligning with the business.
The funniest behavior is that many folks don't even know what a code review should feel like. In my belief, it is more than getting someone else to look at the code before it goes to production. That practice is not really a code review but more like a "commit" review or code approval.
Sadly, the notion of code review is fast disappearing from corporate America especially in shops that have outsourced to all those junior developers in India. Sure, their methodology and heavyweight processes in order to trick enterprises and their process weenie management that they are following best practices does the ceremony of code approval while the talent in the states is sadly waning as no one hear wants to write code and therefore also loose the skill to review.
Should enterprise architects ask themselves, how come code reviews don't happen in their shops. I suspect some of the reasons are:
- Too much pressure to deliver regardless of quality
- No ability to counter the crap given to you by outsourcing firms because you are owned
- Expertise of reviewers simply isn't good enough
- You are lazy and haven't yet taken the step to acknowledge it
- You do reviews yet they always seem to devolve into style arguments rather than code semantics
- You were smart to not outsource but haven't put your developers egos into check and they are delusional and think their code is high quality when reality proves otherwise
- HR has everyone to embrace diversity and sensitivity and code reviews make folks feel sad and unwanted
- You tried pair programming but haven't figured out how to do it when basic communication skills such as U.S. English are non-existent
- You don't have James McGovern on your staff and have acknowledged defeat