paper
active
2015
paper:2023-03-09-stefan-lesser-concept-essay-pdf-161cb7

Towards a theory of conceptual design for software

ByDaniel Jackson
DOI 10.1145/2814228.2814248
Denotational & semantic program designDenotational & semantic program designA concept is a structure that is invented to give a coherent account of the immediate consequences of actions in a complex system.Formal ModelConcepts are not just subjective mental constructs, but are objective features of a system's design: increments of functionality that were consciously introduced by a designer to serve particular purposes.Minimum Viable ProductNo one can serve two masters. Either you will hate the one and love the other, or you will be devoted to the one and despise the other.StyleSystem ImageTrash

TL;DR

Software concepts are objective design artifacts — not subjective mental constructs — that can be formally evaluated for fitness before implementation, and four criteria applied to the concept-purpose mapping (motivation, no redundancy, no overloading, and uniformity) expose real design flaws in products ranging from Adobe Acrobat 9's conflated signature concept to Facebook's pre-2011 friend concept that coupled read-access control with feed curation. The central instrument the paper introduces is the **operational principle**: an archetypal scenario, derived from Michael Polanyi's philosophy of engineering knowledge, that ties a concept's canonical behavioral sequence to its single motivating purpose — a structure deliberately incomplete with respect to all possible behaviors, unlike the formal state-machine models written in languages such as Alloy, B, VDM, or Z that treat all behaviors symmetrically and thus fail to convey meaning. A complementary structure, the **operational misfit**, gives a negative dual scenario that exposes where a concept fails its purpose, illustrated with two specific cases of the Macintosh trash concept (introduced by Apple for the Lisa in 1982): the multi-drive free-space paradox and the metadata-impoverished deletion search problem. Concepts are further organized into a **concept dependence graph**, whose acyclicity and subset-extraction properties define coherent product families — explicitly derived from Parnas's uses relation but applied at the conceptual rather than module level. The paper argues that articulating purposes and operational principles during design, rather than after, functions analogously to constructing a safety case in critical systems engineering and should itself improve design quality independent of external evaluation.

What to take away

  1. 1. A concept is defined as a structure invented to give a coherent account of the immediate consequences of actions in a complex system, making it a design artifact with an associated abstract state machine that encompasses all state and behavior motivating the concept — not merely a conventional datatype.
  2. 2. The operational principle, derived from Michael Polanyi's philosophy of engineering knowledge, is an archetypal scenario that explicitly links a concept's canonical action sequence to its single motivating purpose, and is intentionally incomplete: the schedule operational principle, for instance, describes toggling a slot and the resulting light state but deliberately omits what happens when the current time slot is toggled.
  3. 3. Facebook's pre-2011 friend concept violated the no-overloading criterion by serving two distinct purposes — controlling which users could read posts and curating a manageable reading feed — a flaw corrected in 2011 when Facebook adopted Twitter's follower concept to decouple them.
  4. 4. Adobe Acrobat's concept of object was introduced in version 11 to eliminate the redundancy between three previously distinct concepts (document text, object, and textbox) that all served the same editing purpose, directly illustrating the no-redundancy criterion.
  5. 5. The Macintosh trash concept, introduced by Apple for the Lisa computer in 1982, exhibits two specific operational misfits: emptying the trash to free space on an external drive simultaneously destroys undo history for the main drive, and the absence of deletion-time metadata makes it impossible to search the trash by when files were deleted.
  6. 6. The concept dependence graph, explicitly derived from Parnas's uses relation but operating at the conceptual rather than module level, requires acyclicity — mutual dependence between two concepts signals they are aspects of a single concept — and its minimal subsets define coherent product families including minimum viable product candidates.
  7. 7. Applying concept design criteria requires not only the design (concepts and behaviors) but also the argument (purposes and operational principles), meaning that applying the framework to an existing product requires first reverse-engineering the argument, a step with no counterpart in Nielsen and Molich's heuristic evaluation of user interfaces.
  8. 8. An open question the paper raises is how to determine rigorously when an expressed purpose is composite rather than genuinely singular, given that the no-overloading criterion depends on this distinction yet the paper offers only the heuristic that a conjunctive wording may reveal a compound purpose.
  9. 9. The concept idiom catalog — a repository of reusable concept-purpose-operational-principle triples currently containing approximately 30 entries across six categories (consistency, organization, navigation, access, communication, community) — is proposed as a design knowledge base analogous to Alexander's pattern language but operating at the conceptual rather than implementation level.
  10. 10. To replicate the concept-criteria analysis method, a researcher should for each concept in a target system: (a) articulate a single short-phrase purpose, (b) construct an operational principle scenario connecting canonical actions to that purpose, (c) check all concept pairs for redundant purposes, (d) check each concept for multiple distinct purposes, and (e) compare behavioral operational principles across variant concepts for uniformity — applying these five steps prior to any implementation.

Peer brief — for seminar discussion

Daniel Jackson's concept essay, produced at MIT CSAIL, proposes a formal framework for software conceptual design centered on three technical instruments: the operational principle, the operational misfit, and the concept dependence graph. The work analyzes real products — including Facebook's friend concept before and after its 2011 redesign, Adobe Acrobat versions 9 and 11, Adobe Lightroom 3's rating-stars and flags, the Macintosh trash introduced on the Apple Lisa in 1982, and Git's stash and staging area — to ground four evaluative criteria (motivation, no redundancy, no overloading, uniformity) in observable design failures. The load-bearing claim is that fitness of a software design can be evaluated before implementation by requiring, for each concept, a single articulated purpose and an operational principle — an archetypal scenario connecting canonical action sequences to that purpose — and then checking simple relations between concepts and purposes. The operational principle is explicitly borrowed from Michael Polanyi's philosophy of engineering knowledge, channeled through Michael Jackson's earlier frame-concern notion; it is deliberately incomplete with respect to all possible behaviors, and that incompleteness is a feature rather than a defect, because formal models written in languages such as Alloy, B, VDM, or Z describe all behaviors with equal weight and therefore fail to convey the essential meaning motivating the concept. An alternative representation the paper considers and rejects as primary is the state-transition diagram, which is shown (via Figure 2's conceptless timer description) to be formally correct yet cognitively opaque without the schedule concept's operational principle to structure it. The concept dependence graph extends Parnas's uses relation from modules to concepts, with the key difference that dependences are defined by purposive coherence rather than runtime behavior, so that a paragraph concept carries no dependence on style in the graph even though a specific implementation's paragraph class might hold a pointer to a style object. The graph's acyclicity and subset properties define product families and minimum viable product candidates. What the paper predicts is that constructing the argument (purposes plus operational principles) during design should itself improve design quality, functioning analogously to a safety case in critical systems — independent of any external evaluation pass. A critical reader would push back on the no-overloading criterion's dependence on the granularity at which purposes are described. The paper provides no decision procedure for when two stated purposes are genuinely distinct versus when they are two aspects of a single, more abstractly stated purpose. The call-forwarding example (Pamela Zave's follow-me versus delegate) and the Dropbox deletion example are persuasive, but both are cases where the author has already decided the purposes are distinct. Without an independent test of purpose individuation, the criterion is at risk of circularity: a concept is overloaded when its purposes are distinct, and its purposes are distinct when the concept is overloaded. This is the paper's most significant open methodological gap, and the paper acknowledges it explicitly in the final section, making it both the most contestable and the most honestly flagged limitation in the work.

Methods (1)

Findings (2)

Claims (27)

Hypotheses (1)

Questions (4)

Related work— refs + corpus + external arXiv

Cited / in-corpus / arXiv badges show which signals surfaced each row. Multi-source rows weighted higher.

+30 more

Similar preprints — Semantic Scholar

Cross-corpus bridges (7)

same_concept_as · Nomic cosine

External markdown files that talk about the same concept as this entity.

  • alexander
    Towards a Theory of Conceptual Design for Softwarepapers/extracted/2023-03-09_Stefan-Lesser_concept-essay.pdf_161cb7.md0.872
  • alexander
    Source: https://subconscious.substack.com/p/concept-design-in-three-easy-stepsarticles/substack/2023-05-24_Stefan-Lesser_subconscious.substack.com_p-concept-design-in-three-easy-steps_fda42c.md0.798
  • aboutblank_kb
    Copycat Projectframeworks/copycat-project.md0.781
  • alexander
    Denotational Designpapers/extracted/2022-02-10_Mikael-Brockman_denotational-design-lambdajam-2015.pdf_77a7.md0.772
  • alexander
    Source: https://prapara.substack.com/p/software-synthetic-matharticles/substack/2022-08-21_Stefan-Lesser_prapara.substack.com_p-software-synthetic-math_99fbbd.md0.767
  • alexander
    Source: http://nature-of-order.stefan-lesser.com/geometry-in-softwarearticles/garden/2021-11-17_Stefan-Lesser_nature-of-order.stefan-lesser._geometry-in-software_f919ea.md0.765
  • alexander
    Source: http://nature-of-order.stefan-lesser.com/key-conceptsarticles/garden/2022-04-19_Stefan-Lesser_nature-of-order.stefan-lesser._key-concepts_f60697.md0.754