During a review of CAST Software's latest release of it's Application Intelligence Platform (AIP), they revealed the capability to automatically create fix lists for code based on an automated code review.Â Line items on the fix lists do not get removed until the source code shows that it doesn't have that defect any longer. So what?Â Implementing CAST AIP in the development process facilitates an automated code review every time the work-in-progress code is checked in. There is plenty of evidence, including papers from DCG, that code review is a software development best practice that can be readily cost-justified.Â However, many software development groups still do not do it or they do not do it properly.Â Why not?Â Two main reasons: Either management do not believe the evidence and only see the cost as being an overhead that can be easily removed or the developers are under such schedule pressure that they scrimp on the code reviews (and salve their consciences by assuring themselves that their colleagues are good buddies who probably don't make mistakes). Where does CAST AIP come in?Â One of CAST's strengths is the analysis of source code to identify code bad practice.Â It has been possible for some time to implement CAST to do, say, a code review of an application every night.Â One of the resulting reports allows aÂ team lead or architect to review the code defects and move them to a fix list (actually called an "Action List" in CAST) for the developers.Â This has been a powerful tool for some clients but it has also generated the feedback that the team lead or architect has too much to do besides worrying about this manual intervention (sound familiar).Â Clients have said that some defects just obviously need to be fixed, can't they be automatically added to the Action List? Well, yes, with AIP Version 7.0, they can.Â Given the nightly reporting, those automated actions will keep appearing on the fix list until the defects are removed from the code. So we have automated code review with guaranteed implementation follow-up.Â This would solves one of the key weaknesses of some of the best development team leads and architects that I know!