For some time now, my wife has been complaining about slowdowns on her iMac. Occassionally, I would login and try to do something and I found that the only way for me to login would be to completely reboot the machine. The user switching was essentially non-functional and just left the computer completely hung. Other problems she mentioned were that everytime she started Safari, she would get a message that said the Safari had been updated and would she want to allow the new version to access the same keychain items.

Normally, a user would just have to click the change all button once, but this prompt kept coming back, eventually beachballing the system. Thinking that the two problems were unrelated, I first set out to fix this to get around that annoyance.

I stumbled across the fix for securityd eating up RAM when updating keychain entries on the unsanity.org site. As it turns out, this fix cleared up both problems.

In short, if you dont want to read all the technical details on the unsanity.org article, this was caused by a corrupt CodeEquivalenceDatabase file. The fix was simple enough:

superbia:~ matt$: sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

After a reboot, the system is *MUCH* more responsive and all the annoying keychain notices have ceased.

A colleague of mine, David Starr, has recently started a podcast featuring “elegant coders in the wild”. The first episode is a recording of a monthly breakfast that the elegant code team has here in Boise, which provide some interesting conversations.

The second episode is an interview with the QA Manager here at Healthwise. Scott provides some excellent discussion around his experiences with agile methodologies from the QA perspective. Additionally, he talks about experiences with TFS, Watir, Ruby and Selenium. As expected, Perl was also brought up. :)

You are able to access previous episodes in the elegant code cast archives. While you’re there, go ahead and click one of the buttons to subscribe to the podcast. You wont regret it.

Keep up the great work David. I cant wait to hear more.

If a software development organization needs to put check-in policies in place, then there are some other fundamental problems that are going on within the organization. Check-in policies are just simply a way to mask the symptoms. Let me clarify by citing some common check-in policies and why I think they hide other problems.

A check-in policy for unit tests indicates that the entire team has not bought into the value of unit testing. If they had, then the unit tests would be created and committed as part of the check in process already. No policy would be needed to enforce this. If you have developers that have not bought into this, a policy isnt the right answer. Rather, the individual needs to be coached on the benefits of the unit tests. If after repeated attempts at coaching you find that an individual still does not commit unit tests as part of the check-in process, then personnel action may need to be taken to remove the person from the team. A team, after all, is only as strong as its weakest link.

Check-in policies that require code that is committed be tied to a specific work item sends a message to the team that they are not trusted to execute on the work that they are supposed to be doing. In an agile environment, the entire team should be working together towards a common goal. If you find that this is not happening, the offending team members need to be coached to help them understand the implications of not working together to help the team achieve its goals. Again, if after repeated coaching attempts this does not resolve the problem, then personnel action may need to be taken to remove that person from the team.

Check-in policies for code reviews are ridiculous. The implication with this policy is that people are not working together and developing code in a silo. Not only are they developing in a silo, but there’s concern over whether or not their code is any good. Other agile practices, such as unit testing and pair programming, should go a long way towards eliminating the need for code reviews. Mandating that someone has to put who reviewed their code prior to checking it in though is not the answer. The team should collectively be responsible for delivering a high quality system, and everyone on the team should be responsible for all aspects of the codebase. Forcing this “collaboration” means that the teams are not working effectively together and the manager of the team should look for ways to increase team communication.

I know that there are strong opinions on these items both ways and I am certainly hoping for discussion on this.