Go BackGo Forward Index Home    


Software Development Productivity Monitoring Guidelines and Tips

ProjectCodeMeter enables actively monitoring the progress of software development, by using the Productivity Monitoring process In case the productivity drops significantly and steadily, it is recommended to improve the accuracy of the project design specifications, check target quality definitions, improve work environment, purchase development support tools, reassign personnel to other roles, change development methodology, outsource project tasks which your team has difficulty with, gain experience and training for your team by enrolling them to complementary seminars or hiring an external consultant.
This assumes no motivational issues exist, such as personal issues, compensation, daily experience, goal alignment, and significant interpersonal conflicts.

Studies done by IBM showed the most crucial factor in software development productivity is work environment conditions, as development teams in private, quiet, comfortable, uninterrupted environments were 260% more productive.

The second most important factors are team interactions and interdependency. Wisely splitting the project
development tasks into small self-contained units, then splitting your team into small groups based on these tasks, will reduce the amount of  interactions and interdependency, allow task parallelizing, exponentially increasing team productivity.

In early design stage, creating a simple as possible control flow, modular and intuitive code structure, using clear and accurate function descriptions, and well defined goals, can
significantly reduce development time .

Using source code comments extensively to explain design considerations, usage pitfalls, and external references, can dramatically reduce development and maintenance time on projects larger than 1 man month, increase code reuse, and shorten programmer adjustment during 
personnel reassignment.

Performance review is best done weekly, in order to have enough data points to see an average performance baseline. The purpose of which is for the manager to detect drops and issues in team performance and fix them, not as a scare tactics to keep developers "in line" so to speak, nor as a competitive scoreboard - It should be done without involving the developers in the process, as developers may be distracted or stressed by the review itself, or the implications of it, as shown by the Karl Duncker candle experiment, that too high motivational drive may damage creativity.