1. Project Management

1.1. Project Management

• Project management is a skill

  • It has to be learned

  • It has to be practiced

• Any skill-based class will typically grade you on process

  • Consider taking a class to learn Tennis

• This semester, we will pay a lot of attention to your process

1.2. 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.

  Note

  For me, programming takes a lot of focus and concentration. One concern for me is the many details to remember. I use “todo” lists a lot. I find things like the GitHub Issue Tracker invaluable for bigger projects (but that might be overkill for CS3114 class projects). The key thing is to write down any details that occur to you that you don’t want to deal with right this instant.

1.3. Historical Data

• Relationship between final score on a project (Y axis) and % of total time spent by about a week before the due date (X axis).

1.4. 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

• 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

1.5. 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 (they generally did better) vs. doing work at the last minute (they generally did 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)

1.6. How to fail at implementing your project:

• Write the project

• Debug the project

1.7. How to succeed at implementing your project:

• Use Incremental Development. Begin with a small initial core

  • Implement and TEST and COMMENT the core.

  • Then gradually add functionality.

• The ideal: On any given day, write only as much code as you have time to debug THAT DAY.

• This works well with Scheduling and Organizing.

  Note

  For our projects, you need implementation, comments, and tests. If you write the comments (especially javadoc comments) and the tests when you add a functional unit, its not that big a burden. If you add them at the end, it feels really tedious (and you don’t get any of the benefits).

1.8. Being Organized

• Software development has so many details

  • Spec requirements

  • Program interactions

• So does Life

  • Assignments and other things to do

• 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)

1.9. Milestones

• Big positive effect with milestones (introduced in Spring 2016) vs. without (control group: Fall 2014).

1.10. Working with a Partner (1)

• Typically, about half to 2/3 of students work with a partner.

• 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.

1.11. Working with a Partner (2)

• About 1/3 of partnerships end badly.

  • The common complaint is one blaming the other for “letting me down”.

• Two approaches:

  • Divide and Conquer: Bad

  • Extreme Programming: Good