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.
While being in Boston, I attended the open floor session of the SD Best Practice 2006 conference. I will consolidate my findings from there and publish some of it here too. I was impressed by the many talks and tools for Agile Software development methods.
Next week I will be on a course – learning about the standard development method at my company. This is a classical waterfall model. Since I have been using the Agile Method SCRUM in my last project this will be an interesting contrast and surely a source for discussions.