Predictability in Software Development

In software development, predictability is often an important consideration when selecting a course of action.

A course of action that takes more time, or costs more than another may still be chosen if it offers more predictability in terms of quality of results, time, and costs.

Ultimately, business decisions are being made (and other business activities set in motion) based on the expectation that the development team will deliver according to plan.

Therefore, a course of action that best ensures that the team delivers on time and on target is of great value to the organization.

Reading Notes: Professional Software Development (Part 5)

The author and his company (i.e. Construx) defined the following Knowledge Areas:

• Requirements
• Design
• Construction
• Testing (specifically, activities to detect defects)
• Maintenance (includes deployment and operation)
• Configuration Management (similar to Release Management)
• Quality (activities to ensure that the artifacts meet the technical requirements)
• Engineering Management (all aspects of management)
• Engineering Tools and Methods
• Process (activities related to measuring and improving all aspects of software development)

Reading Notes: Professional Software Development (Part 4)

Personnel Factors

• One study found 20 to 1 difference in productivity between different developers to debug the same program.
• Other studies give similar conclusions, mostly at least a 10 to 1 difference.
• In the Cocomo II model, personnel factors have the following influence on project estimates:
  
  • Experience in the application area: 1.51
  • Communication factor: 1.53
  • Programming language and tools experience: 1.43
  • Personnel continuity: 1.51
  • Platform experience: 1.40
  • Programmer capability: 1.76
  • Analyst capability: 2.00
  • Total Cumulative: 24.60
• The above also implies that senior staff is a critical success factor.
• Motivation is one of the greatest influence on performance.

Reading Notes: Professional Software Development (Part 3)

Capability Maturity Model

• One study shows that:
  
  • 75% of organizations improve from Level 1 to Level 2 within 3.5 years (median of 22 months).
  • 75% of organizations improve from Level 2 to Level 3 within 2.5 years (median of 21 months).
• Another study shows that:
  
  • Teams at Level 1 routinely underestimate development costs. 50% of the projects were up to 100% over-budget. 25% of projects spent 4-5 times the original budget.
  • Teams at Level 2 has most projects slightly over or under budget, with a very small minority (something like 10%) of projects finishing at 2-3 times the original budget.
  • Teams at Level 3 had all projects finishing within a small range of the budget. Those that went over-budget did not exceed the budget by more than 25%.

This means that a team operating at a higher maturity level allows for better overall business planning and execution.

Capability Maturity Model

The CMM is a good way of categorizing organizational software development maturity levels.

The 5 levels are:

• Level 1: Ad Hoc
• Level 2: Repeatable
• Level 3: Defined
• Level 4: Managed
• Level 5: Optimizing

More details: en.wikipedia.org/wiki/Capability_Maturity_Model

When managing a team, it is important to:

1. Understand which level the team is currently operating at.
2. Find out the expected performance, common risks and pitfalls associated with operating at that level.
3. Plan current projects according to the current level which the team is operating at.
4. Identify the risks and mitigate them.
5. At the same time, put in place a plan to bring the team to the next level.

Reading Notes: Professional Software Development (Part 2)

Book: Professional Software Development

Author: Steve McConnell

Great Software Designers

• Able to look at both big picture and details.
• Able to see patterns and apply solutions.
• Have mastery of tools.
• Able to make something complex as simple as possible:
  • "You know that you have achieved perfection in design not when you have nothing more to add, but when you have nothing more to take away" (Antoine de Saint Exupery).
  • "Everything should be made as simple as possible, but no simpler" (Albert Einstein).
• Seek out criticism.
• Learn from failures.
• Persistent.
• Creative.

Individual vs Team

• A study finds that the average programmer only spends 30% of his time working alone.
• Another study found that the biggest contributor to overall productivity is team cohesiveness.

Reading Notes: Professional Software Development (Part 1)

Book: Professional Software Development
Author: Steve McConnell

Project Failure

• 25% of all projects "fail outright".
• 50% of all projects are late, over-budget, or compromised in functionality.

Focus on Quality

• Projects that focused on a low defect count have the highest chances of finishing on target.
• 95% defect removal is found to be the most effective target. The remaining 5% is usually not cost-effective to fix.

Organizational Development Styles

• Process Oriented vs Commitment Oriented.
• Common pitfalls include:
  • Teams that follow process for process's sake.
  • Teams that make members commit long hours, again for its own sake.
• Bottom line is that good people are key ingredients in both cases.
• Whichever style is used, strong understanding of how to wield it effectively is needed.
• It's not "process vs commitment", it's "competence" vs "incompetence".