‘Code Metrics as a Checkin Policy’ – This is a fantastic idea, but too often brushed aside by both senior and junior developers alike as ‘Getting in the way’.
It would be great to measure a project’s success not just by delivery but by it code quality as well. Currently you get an award for shipping on time because that is something the business can see. However you will never get an award for ‘Code Quality’ because the business stakeholders will simply ask ‘Just what does that mean anyway?’.
The answer is simple.. maintainability. You can get a first release out the door, but each subsequent release will be harder and harder because the code quality is getting poorer and poorer. A new developer on the team has real trouble working on the bad code base and as a result their productivity will never match that of the first release. If anything, they will have to ‘hack’ the code to make it work resulting in an even worse code base!
People accept this as the reality of working on legacy projects… and I can’t accept that. We have the tools and processes to make code quality happen: all you need is team of developers who care for quality and have your stakeholders who can buy into the idea.
If you care about Code Quality, check out this entry in the FXCop team blog:
And Grant Holliday goes into how this works with Visual Studio 2008 here: