On Monday I changed departments. After three years of working with telecommunications and enter-/infotainment products I thought it is time to move on and learn something different. I will be working as an internal project management consultant. My first major job is to lead the introduction of agile software development in our organisation. I guess, I will post more about agile development in the future.
Despite using Gmail for my personal communication, I have to use Outlook at work. Mostly, I can deal with it pretty well but I still look for some extra productivity through some extra tool support. Today I read about Xobni, an outlook add-in that I will try once I have an invitation. The video on their home page looks promising.
On Saturday, I went to the store to finally buy a new external drive. For 150 I got a 500GB Sungoo NASD. While being there, I also picked up the new cat in town – Mac OS 10.5 named Leopard.
Back home I installed the drive first. I connected it to my Mac and Win machines. All worked well and I was pretty satisfied.
Then I installed Leopard. About 1h later I had the equivalent of the “Blue Screen of Death”. Reboot – BSOD – Reboot … Search the Internet … I found out that some applications don’t seem to run under Leopard but I haven’t had installed any of them. Reboot – quickly before the BSOD I managed to start the install again. This time I didn’t upgrade but choose “Archive and Install” (note the little options button on the “Select the drive” screen).
1h later and I had a stable system again. Only my NASD disappeared – so I tried to reinstall the drivers – ok – set up the drive – it stalls. After searching the net again, I learned that the NASD software is from Ximeta and their drivers don’t work with Leopard. On their support website you learn that a new driver is planned for Q1/2008.
I’m a bit frustrated as I wanted to use the drive for the new Time Machine feature. I hope Ximeta will bring out the new driver sooner due to public demand.
This can be cool stuff.
Video Searching by Sight and Script
Researchers have designed an automated system to identify characters in television shows, paving the way for better video search.
Last week I attended a seminar about our System Development Method. The course was rather interesting although I was pushing our seminar leader a bit. I feel that my experiences in project management and agile software development added to the seminar although I could have made this less obvious sometimes. I am so used in raising my voice, uttering my opinion and leading people that I now have to learn to take myself back a bit again – I think. I liked the mix of people and I think we were a very homogeneous group. I can truly say that I would like to work with any and all in a team. Most of the seminar attendees can be found on Rene’s web album.
I’d be very interested in the results of the study mentioned in the following article: Technology News: Developer: Putting Open Source Development Under the Scope
A bit more from the article:
How are open source software projects able to set their speed and quality on the best participants? That’s simple: “No meetings,” Berkus said.
“I’m serious,” he continued. “In a large proprietary software development environment, engineers spend four to nine hours a week in meetings, where they are given assignments by managers and expected to work on only their assigned project for the next week. Areas of responsibility are carved out carefully and elaborate quality control and review processes are enforced. The result of all this is to pace the engineers to the plodding pace of management, so that they can stay in control of the project.”
Another reason open source development moves more quickly is that engineers are on the projects they want to work on, limiting procrastination and “sandbagging,” said Berkus.
Lastly, Berkus explained that open source developers are less apt to work on incorrect or buggy code since the project is their own.
“Open source projects are less likely to follow ‘wrong’ specifications, because the same people who write the code are the ones setting the goals,” he noted.
Learning from mistakes made by others is always a good idea. However, the article also looks a common reasons for coding mistakes. I found particular interesting the section on “Why do developers make mistakes?” where
- Ignorance
- Stress
- Boredom
- Human Frailties
were identified as some reasons.
Dr. Dobb’s | Avoiding the Most Common Software Development Goofs | September 17, 2006
Dr. Dobb’s | Code Inspection Book | September 17, 2006
The book summarizes the results of 2500 reviews of 3.2 million lines of code at Cisco.
“The book refers to a number of studies, some of which are relatively obscure. For instance, did you know that when reading a function developers repeatedly return to look at variable definitions? The implication is that short term memory doesn’t hold a lot, so wise teams will insist that all functions fit on a single page. Then it’s easy to glance up at the declarations without shuffling through paper or screens.”
“But engineers achieved the best results when inspecting at about 300 lines of code per hour or less. And after about an hour review effectiveness plummets. We get tired.”
“Expect to find about 15 defects per hour.”
“Authors who “annotate” and explain the code before the review have fewer mistakes. ”
“Best Kept Secrets of Peer Code Review,” is free (in US only, otherwise shipping rates apply) to order on-line at SmartBear. It’s a physical volume, not a PDF.
I have managed an agile project and convincing developers to follow coding conventions isn’t easy. Thus, the following article was interesting for me: Dr. Dobb’s | Coding Conventions: Make Them Agile | September 20, 2006
The main conclusion is that the coding conventions should come from the team themselves, should be simple and localized. “… concentrate on creating an agile coding convention that meets the needs of your agile organization.”
Jospeh Weizenbaum is a computing pioneer and known amongst many for his ELIZA project. Now there is a film about him: Weizenbaum. Rebel at Work.