Overview Coding Practices Balancing standards Configuration Management Providing Change Control Software Estimation Reasons why Programmers and Managers

Coding Practices Good ideas: Let technical lead set standard/practices Strict standards are not always best Have multiple people review each line of code Have project managers sign-off each code section Guidelines, examples, and suggestions sometimes work better than hard and fast rules Circulate well written code to provide examples for others Reward well written code

Standards in Coding Allow the group to develop it’s own coding practices over time rather than forcing them to adopt one style of coding Suggesting different styles of standards to the group may be a good idea to reduce the variation of code

Configuration Management Software is dynamic, and changes are bound to happen. But Configuration Management attempts to control changes. Configuration Management’s biggest goal is to help programmers work more efficiently by having them work on relevant code. If Configuration Management is not followed, problems may never be solved, code can become incompatible, there is no traceable path in your development.

Configuration Management Implementation Suggestions Follow a change procedure Handle changes in groups Evaluation the cost of every change Don’t make too big of changes Develop a judicial change control team Use a bureaucracy system

Configuration Management Additional Thoughts Backup code versions periodically Decentralize data storage in case of disaster Compare new versions with old to spot trends in errors Standardize machine configurations

Software Estimation Most projects are poorly estimated about one year late about 100% over budget There is typically an optimistic outlook on the project of about 20-30%

Software Estimation Methods Take advantage of Project Estimation software, or estimation algorithms Have outside estimation experts consult your team Estimate my sections, and then add up the sections Keep record of previous estimations and the actual project times to adjust your estimates

Software Estimation Suggestions Establish real objectives, and evaluate the estimate based on those objectives Allow enough time for a proper estimate Define software requirements thoroughly beforehand Average the results of several estimations Consider re-estimating the project occasionally

Software Estimation and the Tar Pit Estimation are never going to be 100% accurate, so what happens when we get behind? Hope to catch up Expand team Redefine scope

Reasons for Measurement Having an explanation of why something happened the why it did is better than just observing that it did happen Measurement causes people to focus on resolving known problems Even though estimates and measurements are not always clear, you get some insight into the project

Programmers and Managers Programmers spend time on much more than just programming: Time spent on: Source code: 35% Business: 29% Personal: 13% Meetings: 7% Training: 6% Mail/Documents: 5% Technical Manuals: 2% Misc: 3%

Programmers and Managers Quality and Performance Quality and Performance vary greatly In general 20% of staff perform 50% of work Ratios of good programmers to bad can be as high as 20:1 in regard to performance Interestingly, it seems that good programmers and bad programmers tend to cluster amongst each other

Programmers and Managers Style and Method issues There are several differences that programmers will have based on their opinions of style and formatting Managers need to be aware of: Different opinions Offer suggestions and not rules Focus on the more important issues Allow programmers to develop team standards over time

Programmers and Managers Other considerations The Physical Environment is an important but over looked area that effects a programmers productivity and performance If programmers are satisfied with their work space and office equipment, they are more likely to work better

Conclusion Insist that some kind of coding standard be used Control changes and modifications Attempt to create an estimate in order to measure the projects progression Treat programmers as people

Questions?