I was talking about exploring improvements to our review process, but that isn't the only approach we were taking to better code quality. We were also talking about automated tools like lint, and looking at the unit and system methodology. I'll get to the lint and test issue in a later blog. I was reading what various books and web sites said about effective defect discovery in the development phase, and code review always turned up near the top of the list. The problem was, many programmers are intimidated by allowing others to criticize their work, so to give them the incentive to do it, and often?

One of our team lead managers gave a talk about the Big Ball of Mud. With a title like that, how could I miss it? It was very tongue and cheek, but had a really good message about what we think of software architecture, the projects we work on, and the processes we follow and avoid. It was one of those kick in the pants presentations which encouraged enough engineers to think about how to improve our own software process, even after we thought we had a pretty good one going.