Group: software maintenance
Topic: abstraction
Topic: change
Topic: defensive programming
Topic: design for change
Topic: discrete vs. continuous
Topic: error safe systems
Topic: handling complexity
Topic: hardware vs. software
Topic: interface between program modules
Topic: separate a module's interface specification from its implementation
Topic: software change management
Topic: testing by program mutation
Topic: what is a computer
| |
Subtopic: software difficult to change
Quote: 2nd-5th graders felt it was too difficult to make changes to their KIDSIM science models
| Quote: a library of subroutines may be difficult to change [»utleAM6_1949]
| Quote: use the same order code for new machines since the library of subroutines may be as valuable as the machine itself
| Subtopic: connections between modules
Quote: measure system complexity by the percentage of modules impacted by a change in one module [»belaLA_1979]
| Quote: analyze connections between modules to predicate the total number of changes required to change a set of modules [»haneFM_1972, OK]
| Quote: connections between modules are their assumptions about each other; generally more than calling sequences [»parnDL8_1971]
| QuoteRef: chanRN_1974 ;;10 Measure structure by the assumptions each portion makes on the data objects environment, algorithms
| Subtopic: dependencies
Quote: with MicroTool, difficult to modify a name's definition since its references may become inconsistent; produces an error [»elshJL1_1991]
| Subtopic: increasing complexity
Quote: law of increasing complexity of an evolving program due to deteriorating structure; must be actively corrected [»lehmMM9_1980]
| Quote: the un-structuredness of a system (its entropy) increases with time unless work to reduce it [»belaLA3_1976]
| Quote: software complexity grows unless the software is restructured, either periodically or continuously [»belaLA_1979]
| Quote: without attention, the structure of an evolving program deteriorates and its complexity increases [»lehmMM3_1981]
| Quote: each release of OS_360 had the same amount of modification but effected more modules; last releases effected most modules [»belaLA10_1980]
| Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down [»eickSG1_2001]
| Subtopic: old software
Quote: old changes are difficult to reverse; early decisions should be least likely to change, based on universal truths [»parnDL8_1971]
| Subtopic: need to rewrite system
Quote: plan to throw one away: because of continuous change, it is eventually cheaper to recreate a system [»brooFP_1975]
| Quote: a system that is used undergoes continuing change; eventually better to freeze and recreate it [»belaLA3_1976]
| Quote: despite lots of time spending tidying things, things get in a muddle by themselves [»bateG_1972]
| QuoteRef: brooFP_1975 ;;123 Pascal: "Things are always at their best in the beginning" or CS
| Quote: change or keep a program until it is cheaper to rewrite it
| Quote: a program that reflects some other reality must change continuously or become less useful; eventually need to rewrite [»lehmMM3_1981]
| Subtopic: problem of traceability
Quote: machine code programming allows any change; errors may be hard to trace, especially with index registers [»hoarCA_1974]
| Quote: problem of traceability--how does change in one software artifact (requirement, design, code) affect other artifacts [»clarS11_1999]
| Subtopic: change causes bugs
Quote: change is the primary agent of faults; large, recent changes are the most likely to fail; frequency of change is a better predictor of faults than size of module or number of developers [»eickSG1_2001]
| Quote: while not serious, the number of files touched by a change is a symptom of error-proneness [»eickSG1_2001]
| Subtopic: bugs causing bugs
Quote: 40% of changes to fix errors introduced more errors [»puruR6_2005]
| Quote: software repair should be assigned to those with maximum system overview and insight [»belaLA_1979]
| Quote: in most cases, the cause of a software product failure was introduced while fixing another failure [»cobbRH11_1990]
| Quote: unit verification by debugging may cause design faults when the fixed modules are combined [»cobbRH11_1990]
| Subtopic: sensitivity to change
Quote: software is not soft; to change a system's behavior requires major reprogramming [»fishG7_1987]
| Quote: in a digital device, changing a single bit can have drastic consequences; a radical novelty of computers [»dijkEW12_1989]
| Quote: a randomly altered program rarely serves a useful function; unsuited to evolution [»conrM5_1985]
| Quote: unlike physical systems, software is not continuous; small changes can cause large failures; small requirement changes can cause large design changes [»wegnP_1979a]
| Quote: a trivial, minute change can wreak havoc in a massive system; like the time traveler who damages a butterfly [»demiRA5_1979]
| Quote: apparently innocuous changes to a program can have surprising and disastrous effects [»jackMA_1975]
| Quote: constructing stable software is like constructing a skyscraper that depends on every detail fitting exactly [»fairRE_1985]
| Quote: the idea of tolerances does not apply to software; the building blocks are absolute [»dijkEW_1982]
| Subtopic: continuous vs. discrete
Quote: analog systems can be reliable because they are continuous; small input changes cause small output changes [»parnDL12_1985]
| Quote: in physics, action has local effects (e.g., inverse square law); in computation, a tiny program can clear all of memory [»hillWD_1985]
| Subtopic: independent parts
Quote: variables, arrays, files splits a machine into disjoint areas; updating one does not effect the others [»hoarCA_1974]
| Subtopic: maintaining good structure despite change
Quote: a system must maintain its good structure despite an unending sequence of changes [»belaLA_1979]
| Quote: after each pseudocode refinement, measure its complexity to evaluate the programming process; called the Partial_Metrics_system [»reynRG11_1987]
| Quote: systems built under Mesa will usually remain reliability after changes to interfaces [»laueHC_1979]
| Subtopic: fixing software OK
Quote: did not find error corrections to software causing new errors; could be result of experience or of monitoring development [»weisDM2_1985]
|
Related Topics
Group: software maintenance (14 topics, 368 quotes)
Topic: abstraction (62 items)
Topic: change (28 items)
Topic: defensive programming (22 items)
Topic: design for change (76 items)
Topic: discrete vs. continuous (47 items)
Topic: error safe systems (76 items)
Topic: handling complexity (60 items)
Topic: hardware vs. software (15 items)
Topic: interface between program modules (55 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software change management (48 items)
Topic: testing by program mutation (18 items)
Topic: what is a computer (62 items)
|