SE News

I had to work late and my manager supported by staying late with me. If he was somewhat technical, he could have asked relevant questions or maybe even offered helpful suggestions. But he hadn’t written code in years – and never in the language I was using. He just slowed me down.

I’m now a manager for a team of developers. It’s getting late one afternoon and a customer calls me up and starts yelling in my ear. Some system we sold them was down and they had to produce reports by the following morning or there would be hell to pay.

Of course I stayed late with my developer to solve this customers’ problem. And guess what? Yep, I hadn’t coded in years and never in the language he had to work with. So I could offer very little in the way of technical guidance.

When a manager tells his developers to work late, should he stay late too?

Eric Spiegel

http://itmanagement.earthweb.com/article.php/3854421/When-Developers-Work-Late-Should-Manager-Stay-or-Go.htm

The People Capability Maturity Model (CMM) is a tool that helps you successfully address the critical people issues in your organization. The People CMM employs the process maturity framework of the highly successful Capability Maturity Model for Software (SW-CMM) as a foundation for a model of best practices for managing and developing an organization’s workforce. The Software CMM has been used by software organizations around the world for guiding dramatic improvements in their ability to improve productivity and quality, reduce costs and time to market, and increase customer satisfaction. Based on the best current practices in fields such as human resources, knowledge management, and organizational development, the People CMM guides organizations in improving their processes for managing and developing their workforce.

Bill Curtis
Bill Hefley
Sally Miller

http://www.sei.cmu.edu/publications/documents/09.reports/09tr003.html

Most programmers agree that another pair of eyes on your code will uncover bugs and disseminate knowledge across development teams. But many also recognize that peer review can waste a lot of time.

So how do you get started in such a way that you 1) don’t waste time, 2) match the process to your team and your goals, and 3) have a clear way to evaluate results? So many code review techniques exist, and each with pros and cons, so which are right for your team? Even if you’re unwilling to spend the time to review all your code, perhaps spending a little time reviewing a specific subset would be worthwhile.

The only way to know is to try it for yourself. Use these tips to simplify, expedite, and measure the process.

Jason Cohen
http://www.ddj.com/architect/215800147

It’s widely accepted in the software industry that some programmers are much more productive than others. Many experts cite an order-of-magnitude productivity difference between the “best” and “average” programmers. This “factor of 10″ difference is so commonly referenced that “10X Software Development” is the name of the blog by development productivity guru Steve McConnell.

But it’s not just that some programmers work faster; some programmers can do things that few other programmers can do. These are your visionaries and trailblazers. I call this sometimes-10X/sometimes-infinite advantage: The “Tenfinity Factor.”

Timm Martin

http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/

My last couple of posts on productivity variations among programmers and the Chief Programmer Team model gave rise to some discussion about hazards of measusring software productivity at the individual programmer level. Software engineering studies normally measure productivity in terms of time to complete a specific task, or sometimes in terms of lines of code per effort-hour, staff-month, or some other measure of effort. Regardless of how you choose to measure productivity, there will be issues.

Steve McConnell

http://forums.construx.com/blogs/stevemcc/archive/2008/04/09/measuring-productivity-of-individual-programmers.aspx