Project and Build Management

Bart Massey 2013-11-18


  • Project Management
  • Build and Configuration Management

Project Management: The Textbook Perspective

  • Coding standards and practices

  • Scheduling and estimation

  • Measurement and control

  • Programmers as people

  • Managing your manager

Scheduling and Estimation

  • Problem: Scheduling must, by definition, happen too early

  • Various solutions have been proposed / used:

    • "Experience" (no)
    • Predictive modeling
    • Modeling and simulation
    • Forego scheduling and work "on the fly"
    • No good if there are deadlines or resource constraints

      Predictive Modeling

  • Large histories of characteristics and outcomes of SW projects is compiled

  • A predictor model is built based on history

  • The predictor model is then applied to new projects

  • Most famous, probably best: COCOMO2

Detail Scheduling

  • Traditional scheduling approach is via a "CPM chart" or "Gantt chart":

    • Collect tasks to be done to fine granularity
    • Note dependencies between tasks
    • Note resource usage of tasks (mostly people)
    • Build a schedule (software helps here)
    • Note critical path, slack
  • Problem: Only know detailed end tasks at end

  • Problem: Lots of work
  • Opportunity: Regression to the mean
  • Opportunity: Fewer lost tasks

Measurement and Control

  • First principle (not in book): Only measure something if you intend to use the measurement

  • Measuring can be harder than it looks

  • Control must be small, and results measured carefully (no controls, no time for experiments)

  • Remember that measurement is overhead

Programmers As People

  • Perhaps most important section in book

  • Applies to colleagues, bosses as well as reports

  • Human foibles can be planned for

Programmer Efficiency

  • Going to vary widely (10x?)

  • Going to be way less than 100%

  • Going faster usually loses because rework

  • Culture is especially important because programmer social fail

Work Environment

  • Work environment matters hugely

    • Physical
    • Cultural
  • Tons of information on how to improve

  • Doesn't have to be top-down improvement

"Managing Your Manager"

  • Managers are people too

    • May be too non-technical
    • May be out of date
    • May be personality-defective
    • May be desperately unhappy managing
  • Like any kind of diagnostic problem solving

    • Figure out what the error is
    • Do propagation
    • Make a plan
    • Execute the plan
  • Don't quit willy-nilly, and do find another job first

Configuration management

  • Idea: Have software under control always

    • Use people + tools to have SW that

    • Is composed of known pieces in known ways

    • Is as high-quality as can be reasonably achieved
    • Is "future-proofed" against change in the world

    • Old School: CCB; New Wave: Tool-based

  • It's all about changes: different practices for different project phases

  • It's not just SW

    • Tool versions and machine configurations
    • Backups

Build management

  • Everybody automates build and deployment now

    • Maybe make, maybe very sophisticated build tools

    • Tools like Jenkins that provide "continuous integration"

    • Automated testing

    • Automated packaging, maybe delivery

  • Goal: Achieve CM, QA, V&V on a fine-grained basis without much human overhead

  • Learn to work with this stuff

    • Learn to use Git
    • Write the build scripts
    • Write the unit tests

This Class Is Not A Team Project Class

  • Note that the practices advocated for in this lecture are almost all useful regardless of project and team size

  • YMMV

Last modified: Tuesday, 19 November 2013, 11:34 PM