Topic: software management

topics > computer science > programming > Group: software engineering

software maintenance

Cleanroom software development
design documentation
extreme programming
incremental development
management of large software projects
programmer productivity
programming environment
quality assurance
reusable programming
software change management
software lifecycle
software metrics
software review
system builds
team programming


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 up

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 up

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 up

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 up

Quote: software development resembles a dynamically overloaded queue like a rush-hour traffic jam; chronic overload for everyone [»olseNC9_1993]

Subtopic: need tools up

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 up

Quote: 1000 UNIX systems even though it was developed by two people in an attic in a year [»kernBW1_1979]

Subtopic: cost up

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 up

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 up

Quote: pair programming--better quality, completed on time, enjoyed it more, more confident in their solutions [»willL7_2000]

Subtopic: maintaining standards up

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 up

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 up

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 up

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 up

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)

Updated barberCB 3/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.