Group:
software maintenance
Topic:
Cleanroom software development
Topic:
design documentation
Topic:
extreme programming
Topic:
incremental development
Topic:
management
Topic:
management of large software projects
Topic:
programmer productivity
Topic:
programmers
Topic:
programming environment
Topic:
quality assurance
Topic:
reusable programming
Topic:
software change management
Topic:
software lifecycle
Topic:
software metrics
Topic:
software review
Topic:
system builds
Topic:
team programming
| |
Summary
The software manager's job is particularly difficult. He or she is expected to make schedules and meet deadlines but software progress is difficult to monitor. Projects in trouble, end up in bad trouble with little warning. There is just too much uncertainty. The best he can do is provide a productive environment for these that perform. The non-software manager of programmers is in worse shape because he can not control the process. Managers would like linear development of clearly defined software with easily modified goals in case trouble looms. (cbb 5/80)
Subtopic: resources and people 
| Quote: software engineering should include resource engineering and human relations [»boehBW_1979]
| | Quote: software engineering is the multi-person construction of multi-version programs [»parnDL_1978]
| | Quote: quantified quality requirements are not important; projects succeed or fail because of weak sponsors, isolation, poor leadership, sloppy design, sloppy testing [»cockA3_2008]
|
Subtopic: risk management
| Quote: software projects should emphasize risk management: what can go wrong, what would happen, and what has been corrected [»boehBW5_1984]
| | Quote: software production should be a continuous process; and the absorption of uncertainties should be partitioned [»simoC12_1976]
| | Quote: software is expected to absorb too much uncertainty; from customer needs to documentation [»simoC12_1976]
| | Quote: uncertainty absorption is the promise of action which enables others to operate free of uncertainty
| | Quote: uncertainty absorption is simplest when a process is continuously reassured, controlled, and optimized [»simoC12_1976]
| | Quote: add 20-50% buffer time to each milestone for unexpected difficulties and unplanned features [»cusuMA10_1999]
|
Subtopic: schedule
| Quote: delete features if behind schedule
| | Quote: business deadlines strongly influence overall productivity; large versions under deadline more productive than incremental versions [»potoTE10_1999]
|
Subtopic: chronic overload
| Quote: software development resembles a dynamically overloaded queue like a rush-hour traffic jam; chronic overload for everyone [»olseNC9_1993]
|
Subtopic: need tools
| Quote: build programming tools instead of relying on unskilled help [»mcilMD7_1978]
| | Quote: insufficient computer time for building Multics; should have reduced programming staff and bought hardware [»corbFJ_1979]
|
Subtopic: low cost
| Quote: 1000 UNIX systems even though it was developed by two people in an attic in a year [»kernBW1_1979]
|
Subtopic: cost
| Quote: software should be designed-to-cost since the cost of programming a function can vary widely [»millHD_1979]
| | Quote: basic functions form a small fraction of a software system; most is spent in the user interface, error handling, etc.; easily prioritized [»millHD_1979]
| | Quote: ninety percent of aggravation in programming projects comes at the end; the unimportant, last 10%, could be dropped [»weinGM_1982]
| | QuoteRef: bateD_1976 ;;20 Ramamoorthy '74: "Delay in delivery is commonplace while gross underestimation of the cost by a factor of four is not unusual.
|
Subtopic: graphic design
| Quote: use graphic designers for the visual elements in a user interface; they can communicate more information in less space [»tognB_1992]
|
Subtopic: pair programming
| Quote: pair programming--better quality, completed on time, enjoyed it more, more confident in their solutions [»willL7_2000]
|
Subtopic: maintaining standards
| Quote: under schedule pressure, extreme programmers drop test cases, refactoring, testing, GUI standards, and documentation; the painful parts of XP [»berrDM10_2002]
|
Subtopic: terminating a project
| Quote: upper management must expect that some software projects will be killed before completion [»weinGM9_1982]
| | Quote: software projects which failed badly were never killed by their own managers at early stages despite indications of disaster
|
Subtopic: nightly build
| Quote: software check in must happen by 2 or 5 p.m. so that a new build is ready the next day [»cusuMA6_1997]
| | Quote: most developers check in code two or more times per week
|
Subtopic: rigid management
| Quote: software projects which failed often had managers trying to control employees with overstructured models of behavior [»weinGM9_1982]
| | Quote: a long-range plan can not be rigid; otherwise it becomes unrealistic and is ignored [»alexC_1975]
|
Related Topics
Group: software maintenance (14 topics, 368 quotes)
Topic: Cleanroom software development (38 items)
Topic: design documentation (43 items)
Topic: extreme programming (6 items)
Topic: incremental development (74 items)
Topic: management (27 items)
Topic: management of large software projects (63 items)
Topic: programmer productivity (57 items)
Topic: programmers (15 items)
Topic: programming environment (46 items)
Topic: quality assurance (22 items)
Topic: reusable programming (77 items)
Topic: software change management (48 items)
Topic: software lifecycle (13 items)
Topic: software metrics (32 items)
Topic: software review (80 items)
Topic: system builds (43 items)
Topic: team programming
(7 items)
|
