Group:
program design
Group:
program module
Group:
software engineering
Group:
software maintenance
Topic:
Cleanroom software development
Topic:
configuration management
Topic:
design for change
Topic:
execution with program stubs
Topic:
functional programming
Topic:
incremental compilation
Topic:
incremental execution
Topic:
incremental testing
Topic:
programming environment
Topic:
public domain software
Topic:
software change management
Topic:
software components
Topic:
software lifecycle
Topic:
software maintenance by patching
Topic:
software management
Topic:
source-rich system
Topic:
stepwise refinement
Topic:
system builds
Topic:
Thesa as a database of modules
Topic:
transformation of programs
Topic:
user-centered design
Topic:
user interface design
Topic:
version control
Topic:
words defined by words
| |
Summary
The key idea in Thesa is incremental programming. Everything is incremental: database, development, testing, specification, implementation, code generation, and grammar. Just make one step at a time, keep track of where you're heading, and move on. Under incremental development, a programming system evolves into a potentially large application in a specific environment. The system can be developed by incremental refinements from an overall view or it can be developed by incremental generalization of known instructions. In either case it produces many intermediate layers between description and code.
Incremental development implies intermediate experimental systems. These allow the system to be worked out in practice; like the painter trying a dab of paint and stepping back or the mathematician modifying a theorem during the search for an elegant proof. Only through this constant give and take can a system's performance and costs be balanced. Incremental development is not universally accepted. (cbb 5/80)
Subtopic: programming is incremental 
| Quote: one does not write programs, one grows programs in teams [»bergT9_1997]
| | Quote: in programming, always doing something which is similar to what was done before but seldom exactly the same [»cbb_1973, OK]
| | Quote: programming is a trial and error craft [»parnDL12_1985]
| | Quote: compares the cathedral model of commercial software vs. the bazaar model of Linux and free software [»raymES3_1998]
| | Quote: incremental computing is the best for creativity [»smitDC6_1975]
| | Quote: premature commitment -- avoid making a decision before there is information to do so [»joneSP8_2003]
|
Subtopic: development as theater
| Quote: theater consistently produces quality outcomes on schedule; intensely iterative and adaptive process
| | Quote: should software development be more like theater than manufacturing? [»austRD10_1999]
|
Subtopic: incremental architecture
| Quote: every year produce a diagnostic map showing which spaces work well and which do not [»alexC_1975]
| | Quote: piecemeal growth is healthier than large lump development; avoids slums due to under-maintained, older buildings [»alexC_1975]
|
Subtopic: incremental requirements
| Quote: need better ways to elicit and define requirements incrementally; not a language or structured analysis [»pottC9_1993]
| | Quote: during product development at Microsoft, the feature set may change 30% or more from the original specification [»cusuMA6_1997]
| | Quote: evolve feature set during product development; may change 30% or more over life of project [»cusuMA10_1999]
|
Subtopic: incremental design
| Quote: both design and implementation are interleaved in a real project. Design is usually re-design from the previous design, experience, and constraints [»stroB_1991]
| | Quote: synchronize and stabilize -- evolve designs interactively with frequent synchronization and periodic stabilization [»cusuMA10_1999]
| | Quote: synchronize and stabilize works well for rapid, flexible software development; interviews at Netscape and Microsoft [»cusuMA10_1999]
| | Quote: incremental design is expected for hardware, e.g., breadboards and test machine; not so for software [»corbFJ_1979]
| | Quote: software design should be an iterative process [»pearDJ7_1973]
| | Quote: should design until you think you understand a problem; code until you realize you don't; then iterate [»pearDJ7_1973]
| | Quote: exploratory development environments provide rapid turnaround for building large applications by iterative evolution [»goldA_1986]
|
Subtopic: incremental user testing
| Quote: iterative testing of users is the single most important recommendation for user interface design [»goodMD10_1984]
| | Quote: the need for user testing demonstrates that rational analysis is not sufficient for system design [»goulJD3_1985]
| | Quote: satisfactory man-machine systems are the product of iterative design in which misfits are painstakingly removed [»brooFP8_1977]
| | Quote: user testing demands iterative development to fix problems [»goulJD3_1985]
| | Quote: often the right decision can only be determined by implementation; especially in human engineering and user requirement problems [»simoC12_1976]
|
Subtopic: top-down stepwise development
| Quote: use iterative enhancement with top-down stepwise refinement [»basiVR9_1975]
| | Quote: a software system should be incrementally grown by top-down development with program stubs [»brooFP_1986]
| | Quote: in top-down design, a proper top can execute early in development; allows iterative process of code, integrate, and test [»millHD_1979]
| | Quote: Cleanroom develops software incrementally with statistical quality control; if too many errors then improve process [»millHD9_1987]
|
Subtopic: component development
| Quote: C++ development consists of repeatedly: create a design, find and customize standard components, create and customize new standard components, and assemble the results [»stroB_1991]
| | Quote: inheritance allows the creation of a new class from existing classes; i.e., incremental program development [»taivA9_1996]
| | Quote: without late binding, newly defined components may not work with inherited operations; needed for incremental development [»taivA9_1996]
| | Quote: inheritance with late binding, self-reference, and super-reference allows objects to be reused without textual copying or editing; a new way to write programs [»taivA9_1996]
| | Quote: late binding and self-reference allow a programmer to change object behavior without access to its representation
| | Quote: super-reference allows access to redefined properties without code duplication
|
Subtopic: incremental data
| Quote: in FQL, can incrementally define data; no pre-defined schema [»buneP1_1981]
| | Quote: punch input data, master routine, and subroutines separately; each tape punched twice and compared to catch errors [»wilkMV_1951]
|
Subtopic: scheduling
| Quote: add 20-50% buffer time to each milestone for unexpected difficulties and unplanned features [»cusuMA10_1999]
| | Quote: delete features if behind schedule
|
Subtopic: many small changes
| QuoteRef: smitDC6_1975 ;;61 painters dab on a bit of paint and then step back to look at the result .#@#
| | Quote: in SEL, programs written by many small changes to initial code; 40% correct errors, usually successfully [»weisDM2_1985]
| | Quote: unplanned design modifications for optimization, improved services, or improved clarity and maintainability [»weisDM2_1985]
| | Quote: found most changes to initial code were unplanned; but did not cause new errors
| | Quote: after error corrections, unplanned design modifications were most common
| | Quote: more than 75% of all changes to software took a day or less to make; large changes were infrequent [»weisDM2_1985]
|
Subtopic: simple prototype to complete system
| Quote: always build a preliminary program before delivering to a customer; study timing, storage, and critical design/operation areas [»roycWW8_1970]
| | Quote: before building a fancy program, try a simple prototype to learn about desired features and to collect statistics [»bentJ5_1985]
| | Quote: in structured growth, a simple, initial program is allowed to grow by adding new facilities and deepening existing ones; naturally occurs [»sandE3_1978]
|
Subtopic: every build can ship
| Quote: release early and often, delegate everything, be open; works well despite chaotic change [»raymES3_1998]
| | Quote: Microsoft uses synch-and-stabilize, daily build, and zero-defect; work in parallel but synch and debug daily with a shippable product; common language, continuous testing, milestone and release metrics [»cusuMA6_1997]
| | Quote: recommends planned, incremental development of system with every version capable of running under field conditions; no planned, throw-away code [»brooR9_1993]
| | Quote: to avoid delusion, should build complete, intelligent systems with real sensing and real action; enhance incrementally [»brooRA1_1991]
|
Subtopic: daily build
| Quote: Microsoft uses synch-and-stabilize, daily build, and zero-defect; work in parallel but synch and debug daily with a shippable product; common language, continuous testing, milestone and release metrics [»cusuMA6_1997]
| | 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: if a developer breaks the build, it must be fixed immediately [»cusuMA6_1997]
| | Quote: synchronize and stabilize -- daily builds, two or more milestones, frequent alpha and beta releases [»cusuMA10_1999]
|
Subtopic: rapid code-test
| Quote: rapid code-test cycle using on-line construction sets of example programs, frames, scripts, functional index, alphabetical index, and debugging support [»akscRM11_1993]
| | Quote: Dylan used separate processes for development and execution; the development process downloaded compiled definitions and libraries to the runtime process [»dumaJ6_1995]
| | Quote: ahead-of-time debugging: execute statements as they are typed and update the program state for test cases; better code faster; users liked it [»snelJL7_1997]
| | Quote: can always revise a Smalltalk method or class definition with the editor [»teslL8_1981]
| | Quote: to create a Smalltalk class, select a class category; fill in a template in the editing pane and compile [»teslL8_1981]
| | Quote: once a Smalltalk method is successfully compiled, its selector is automatically listed in the method pane and its pattern is boldfaced [»teslL8_1981]
| | Quote: a Forth system is mostly source; facilitates changes and additions [»rathED10_1976]
| | Quote: program in Forth by writing small pieces which are readily tested [»bailGV8_1977]
|
Subtopic: sketching
| Quote: animators make a story reel showing unanimated sketches; slowly changed into the finished product [»heckP_1984]
| | Quote: a story sketch should show the character, attitude, feelings, ... as well as telling the story; should convey excitement [»heckP_1984]
| | Quote: programming by sketches for rapid development; generate efficient code from clean, portable reference code by sketching the outlines of the desired implementation [»solaA6_2005]
| | Quote: given the same time budget, novice StreamBit users (sketching) produced 2.5x faster cipher code than experienced C coders; competitive implementations of DES and Serpent [»solaA6_2005]
| | Quote: demonstrate sketching the DropThird algorithm; i.e., drop every third bit from the input stream; surprisingly difficult [»solaA6_2005]
|
Subtopic: problems with incremental development
| Quote: system can not at the same time be programmable, efficient, and amenable to evolution [»conrM5_1985]
| | Quote: can not test a partially completed program until all parts are implemented or simulated
| | Quote: Multics developed incrementally; no one person could understand the effect of a module on the system [»corbFJ_1979]
| | Quote: Multics should have used minimal implementations for each set of ideas [»corbFJ_1979]
| Quote: separate compilation not necessary; can perform global analysis, C code generation, and recompilation of modified files
[»zendO10_1997]
|
Related Topics
Group: program design (13 topics, 454 quotes)
Group: program module (10 topics, 336 quotes)
Group: software engineering (18 topics, 470 quotes)
Group: software maintenance (14 topics, 368 quotes)
Topic: Cleanroom software development (38 items)
Topic: configuration management (25 items)
Topic: design for change (76 items)
Topic: execution with program stubs (5 items)
Topic: functional programming (45 items)
Topic: incremental compilation (3 items)
Topic: incremental execution (22 items)
Topic: incremental testing (26 items)
Topic: programming environment (46 items)
Topic: public domain software (9 items)
Topic: software change management (48 items)
Topic: software components (11 items)
Topic: software lifecycle (13 items)
Topic: software maintenance by patching (27 items)
Topic: software management (28 items)
Topic: source-rich system (27 items)
Topic: stepwise refinement (25 items)
Topic: system builds (43 items)
Topic: Thesa as a database of modules (23 items)
Topic: transformation of programs (27 items)
Topic: user-centered design (65 items)
Topic: user interface design (36 items)
Topic: version control (34 items)
Topic: words defined by words
(25 items)
|
