0.Project Management§

Scheduling

Managing large-scale projects involves scheduling activities
It is human nature to work better toward intermediate milestones.

The same concepts can/should be applied to mid-sized projects encountered in class.
For any project needing more than a week to complete, break into parts and design a schedule with milestones and deliverables.
Find some way to keep track of details.

Historical Data

Programmer time data
X axis is % of total time spent by about one week before program due date.
Y axis is score.

Historical Data 2

Results were significant:
90% of scores below median were students who did less than 50% of the project prior to the last week.
Few did poorly who put in > 50% time early
Some did well who didn’t put in >50% time early, but most who did well put in the early time

Historical Data 3

Correlations:
Strong correlation between early time and high score
No correlation between total time spent and score
No correlation between % early time and total time

What is the Mechanism?

Correlations do not necessarily mean causation
Do they behave that way because they are good, or does behaving that way make them good?
But, we have data from students who sometimes spread their work over time (and generally doing better) vs. doing work at the last minute (and generally doing worse)
Why would this matter?
Spreading projects over time allows the “sleep on it” heuristic to operate
Avoiding the “zombie” effect makes people more productive (and cuts time requirements)

How to fail at implementing your project:

Write the project
Debug the project

How to succeed at implementing

Write the smallest possible kernel
Debug that kernel thoroughly
Repeat until completion:
Add a functional unit
Debug the resulting program
Have a way to track details
Do mechanics early
Do structural design before implementation
Implement the tricky parts last

How to Survive

Keys to success:
Keeping Track of all the details
You can’t remember it all
Rational Planning (and keeping to the plan)
Spread the work over time
Incremental Development
Interleave writing and debugging

Being Organized 1

Software development has so many details
Spec requirements
Program interactions
So does Life
Assignments and other things to do

Being Organized 2

You can’t turn this on/off
Either you get in the habit of developing in an organized way, or you can’t succeed as a software developer
Part of it is developing the attitude of “sweating the details”
Part of it is having the coping mechanisms to handle the details (organizational tactics)

Memory Can’t Handle It

Externalize
TODO lists (What)
Scheduling (The Plan for How)
Issue trackers
Documenting/Commenting
Be able to update lists at any time,
Repository: GitHub

Spread Work Over Time

For anything beyond a small software project, you must have a plan/schedule
Explicitly develop a schedule:
Break into pieces: List of subtasks
Deadlines for subtasks
Realistic, enough flexibility built in
Continuously modify and refine the plan

Incremental Development

Break the project into a small initial core
Implement and TEST and COMMENT the core
Then gradually add functionality
On any given day, write only as much code as you have time to debug THAT DAY
This works well with Scheduling and Organizing

Milestones

Big positive effect with milestones (S16) vs without (F14)
     
A 43% 23%
B 16% 22%
C 11% 11%
D/C- 8% 6%
F 4% 5%
Drop 19% 33%

Working with a Partner (1)

Typically, about half to 2/3 of students work with a partner (CS3114).
As a population, we cannot distinguish differences in performance in terms of score distribution between partnerships and singles.
Data indicate that each member of partnership works about 80% as much as a person working alone.

Working with a Partner (2)

About 1/3 of partnerships end badly (CS3114).
The common complaint is one blaming the other for “letting me down”.
Two approaches:
Divide and Conquer: Bad
Extreme Programming: Good