What is complexity?
What can we do about it?
- quantify the problem
- define it
- suggest how to address it
Now take that developed code and have a single developer re-enter it (scenario B). The developer is likely to be able to code at least 1,000 lines of code per day and it would only take about 50 man days to enter the entire program.
The difference between scenario A and scenario B is 950 days to create the same software system. So what are we doing in the other 950 days if it only takes 50 days to write the code?
95% of a project is about solving problems, not writing code
In scenario A we don't know which lines of code to write, time is expended in figuring out:
- determining what the actual requirements are
- translating the requirements into high level design
- designing an architecture sufficient to support the requirements
- translating the high level design into programming languages / libraries
- discovering where the code defects are
- rewriting code for incorrect functionality
Most developers are unable to sit and plan away from the computer, so when you see them at their keyboards they are primarily thinking. They will write and rewrite sections of code as they think through the problems (see Not Planning is for Losers).
Complexity comes from team resources not understanding how to solve the problems they face. When confronted with a problem the team must think about how to solve it.
We spend 95% of our time considering alternatives and hitting dead ends.
Complexity is not a issue if enough time has been budgeted in the project for the team to think things through. Complexity is a problem when you need to think through issues and insufficient time is budgeted.
Projects run late mainly because of two reasons:
- Insufficient time
- You did not use formal estimation techniques and underestimate the project
- You use formal estimates and executives push for a delivery date independent of the problems to be solved in the project
- You estimated sufficient time for your team's skill level to solve the problems but you did not have all the requirements
Look at the following cars:
- How fast does the car need to go?
- How many people does it need to seat?
- What kind of fuel economy do you want?
- What safety features are required?
- How sophisticated do the controls need to be?
The more experienced a resource, the less time they need to think about the final solution. The less experienced resources need more time to think through problems, especially when they hit dead ends.
- For the business analysts and product managers
- This is about understanding the subject matter and making sure to gather enough consistent requirements
- For the developers
- This is about understanding the subject matter for high level design, and understanding the language and libraries for implementation
- For the project managers
- This is about understanding how capable the team is and making sure that sufficient time is budgeted for them to solve all problems
- For the IT executives
- This is about understanding that any given project team needs sufficient time to solve problems and not caving into executive pressure to arbitrarily shorten projects
- Jones, Capers.SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
1 Lines of code is a terrible metric and is only used here to illustrate a point about complexity. Software measurement should use function points or another relevant metric.