Categories

Card Categories

everyone-designs-devises Everyone designs “Everyone designs who devises courses of action aimed at changing existing situations into preferred ones.” [Simon 96] 1
everyone-conceive-things Everyone creates Everyone can conceive of new things. Creativity is not limited to a select few. Technology, including AI, can help people bring their conceptions to fruition. [Dagstuhl 25] 2
youre-struggling-implementation No amount of technology can fix a bad idea If you’re struggling with the implementation, re-examine your goal. [Harger 25] Experts are alert to evidence that challenges their theory.[Experts 16] 3
consider-implications-technology Just because you can, doesn’t mean you should Consider the implications of your technology. [variously attributed] 4
simon-focused-design Problem setting is as important as problem solving Simon focused on design as problem-solving. [Simon 96] Schön focused on design as problem-setting. [Schön 84] [Visser 06] 5
mental-crafting-conceptual Distinguish essential from accidental complexity The mental crafting of the conceptual construct of software is the essence; the implementation process is the accident. [Brooks 86] Experts focus on the essence. [Experts 16] AI is better at the accident than at the essence. 6
alternatives-incomplete-interact Your system probably doesn’t have a unique structure or representation The alternatives will all be incomplete, and they will interact. [Stuff I figured out] The physical parts of a motorcycle aren’t the same as its functional systems – the same part can contribute to more than one system. [Zen Moto 74] 7
divide-conquer-doctrine It’s easier to divide than it is to conquer “Divide and conquer” doctrine says to break your problem into smaller parts, solve the parts, and assemble the parts into the solution. But it’s a lot easier to “divide” than to “conquer”. Independently developed parts are often incompatible. [Stuff I figured out] 8
designs-there-scarce Identify the scarce resource and manage it carefully In most designs there is a scarce resource. The key to successful design is to identify this resource and allocate it carefully. [Brooks 10] Safety first. In allocating resources, strive to avoid disaster rather than to attain an optimum. [Lampson 83] 9
experts-options-experts Consider many alternatives Experts keep options open. [Experts 16] Explore the design space broadly; compare high-level alternatives, don’t just dive deep on the first idea. [Shaw&Petre 24] [Cross 07] 10
specify-properties-realization Specify “what”, not ”how” Specify the properties, not the realization. Distinguish the model of the problem in the world from the model of the solution in the machine. [Jackson 95] Distinguish the outer and inner environments; you can only affect the latter. [Simon 96] 11
experts-explore-different Reframe your problem; reinterpret the situation from a new point of view Experts explore different perspectives. [Experts 16] Rigid adherence to a narrow model or uncritical acceptance of conventional wisdom deters you from exploring a variety of alternatives. Defaulting to a familiar solution can lead to misfit solutions. [Shaw 23] 12
consider-things-materials Consider affordances Consider all the things your materials and resources can contribute, not just their explicit uses. [Norman 88] Experts do not feel obliged to use things as intended. [Experts 16] 13
similar-problem-method Import ideas from other fields; adopt and adapt their problems or techniques “Have you seen a similar problem? Can you use its method? Can you use its result? What are the unknowns?” etc. [How to Solve It 45] Look for similar structures in other fields – they may not fit exactly, but they’ll make you think. [Shaw 23] 14
opportunities-stuff-figured Look for dissonance between what everyone says and what everyone does Opportunities lie in this gap. [Stuff I figured out] [Shaw 23] When the terrain disagrees with the map, trust the terrain. [Swiss Army Proverb] 15
experts-generate-alternatives Question authority; rethink assumptions Experts generate alternatives. [Experts 16] “sometimes he feels that there really is another way, if only he could stop and think of it.” [Edward Bear, bumping down the stairs, Pooh 26] [Timothy Leary, maybe Socrates] 16
contrary-confirming-evidence Take different perspectives intentionally and contrast them critically Look for contrary as well as confirming evidence. Look for structural resonance or dissonance between problems and solutions. Alternate between expanding the design space and limiting attention to essential details. [Petre&Shaw 25] 17
parameters-capture-designers There are two kinds of change: anticipated and unanticipated. Use parameters for the former, use editors for the latter Parameters capture the designer’s intentions for anticipated variability. [Butler Lampson] 18
engineering-about-important No amount of tool, process, or method can replace actually understanding the problem and caring about its solution Engineering is about how to make the important decisions. Tools, processes, and methods (including AI) can make this more efficient but they do not replace thinking. [Stuff I figured out] Neither abstraction nor simplicity is a substitute for getting it right. [Lampson 83] 19
prototypes-built-explore The prototype is not the product Prototypes are built to explore particular design questions; they are usually not suitable as the primary basis for a product. [Stuff I figured out] Plan to throw one away. [Brooks 95] cf vibe coding 20
there-single-correct “It depends” There isn’t a single correct answer, it depends on the client, the context, ... [Stuff I figured out] 21
other-formal-verification Correctness is a social construct Other than formal verification of formally specified code in a sound language, the standard for correctness is negotiated among the participants. [Lakatos 76] [Proof 25] [DeMillo&Lipton&Perlis 79] 22
blind-leading-blind Consensus is not correctness The blind leading the blind is not a substitute for adequate definition and documentation. Crowdsourcing and Q/A communities provide suggestions, but their consensus might be wrong. [Stuff I figured out] 23
costs-tracked-space Time is not money Costs can be tracked in time, space, attention, bandwidth, etc. Their measurement properties differ (fungibility, rivalry, perishability, ratio vs ordinal scale, ...). Converting everything to money is convenient, but it loses nuance and may introduce errors. [Poladian&al 03] 24
privacy-reliability-usability You can’t get security into a system by sprinkling it like pixie dust on your completed code ... nor privacy, nor reliability, nor usability, nor performance, nor ... These properties must be designed into the structure and fabric of the system, into its very architecture. [Stuff I figured out] Retrofitting reliability to an existing design is very difficult. [Lampson 83] 25
doing-moving-program Moving from a program to a product increases the complexity and effort by a factor of 3; so does moving from a program to a system Doing both, moving from a program to a system product, costs a factor of 9 – about an order of magnitude. [Brooks 95] Each step has higher demands for reliability, security, usability, correctness, safety, performance, and other quality attributes. cf vibe coding 26
system-standard-dialogs Less than 10 % of the code goes to the overt function of the system; the rest goes to housekeeping ... such as system code, I/O, standard dialogs, UI, data validation, audit trails, communication, and so on. [Stuff I figured out] [Shaw 95] [Bentley 88] [many places online] We can hope that AI will take over a lot of the remaining 90%. 27
engineering-creates-cost-effective Seek cost-effective solutions to practical problems Engineering creates cost-effective solutions to practical problems by applying systematic knowledge to building things, in the service of mankind. It entails decisions constrained by limited knowledge, time, and resources. [Shaw 90] [Manifesto 05] 28
theres-spectrum-enough Satisfice – fitness for the task at hand is often a better goal than formally verified correctness There’s a spectrum from “good enough” to “must be correct”, choose the right point. [Stuff I figured out] [Shaw 20] This is a form of satisficing. [Simon 96] 29
project-failures-arise Allow the engineer to be utterly faithful to the engineering integrity of the engineered artifact Many project failures arise from management getting in the way. [Squires 86] 30
evaluate-things-critically Think, don’t just count Evaluate things critically and thoughtfully. Counting things is often a poor proxy for what you really care about. [Stuff I figured out] cf bibliometrics 31
measure-objective-directly Measure what matters If you can’t measure your true objective directly, beware of proxy measures. “When a measure becomes a target, it ceases to be a good measure” – people will pursue the target (instead of the real goal, if they are different). [Goodhart’s Law] cf the H-index 32
theres-difference-between Don’t confuse ONE way with THE way There’s a difference between ? and ?. Many methods, tools, and processes are sometimes useful, and it’s usually good for the whole team to be on the same page. But no method, tool, or process is uniquely the best. [Stuff I figured out] 33
engineering-routine-design Reuse proven solutions when you can In engineering, routine design selects established solutions to well-known problems. Innovative design finds novel solutions to unfamiliar problems. Choose routine engineering when it works for you. [Shaw 90] Experts prefer solutions that they know work. [Experts 16] 34
experts-tradeoffs-experts Make deliberate tradeoffs among resources and among quality attributes Experts make tradeoffs. [Experts 16] Pay special attention to the generality/power tradeoff. “Faster, better, cheaper, choose two”? No, choose some of each. [Stuff I figured out] 35
physical-therapy-before Exhaust less drastic, reversible options before turning to more drastic, irreversible ones Try physical therapy before surgery. [Stuff I figured out] 36
humor-especially-satire Satirize: ridicule absurdity Humor, especially satire, can be a safe way to say things that are otherwise unacceptable. [medieval court jesters] 37
stakeholders-competing-implicit Problems embedded in society are not often solved using the ordinary methods of analysis Many stakeholders, competing implicit goals, and irreversible actions rule out clear problem definitions and success criteria. These are Wicked Problems.[Wicked 73] 38
chase-stuff-figured New technology doesn’t necessarily invalidate old theory, though it may require adaptation Don’t chase fads. [Stuff I figured out] The information economy was said to need a whole new economic theory. But no, the old economics works just fine, just with new parameters. [Info Rules 99] AI will not make SE obsolete. [Kang&Shaw 24] 39
choose-prevention-consequences There are two ways to deal with the possibility of Bad Things: prevention and remediation Choose prevention when consequences are dire – remediation is often preferable the rest of the time. [Stuff I figured out] [Shaw 06] 40
doesnt-everyone Correlation is not causation Doesn’t everyone know this? 41
where-consequence-failure Automate things that are well-understood, tedious, and error-prone when left to humans ... and where the consequence of failure is manageable. Everything else, plus oversight, is human responsibility. [Stuff I figured out] [Kang&Shaw 24] 42
assume-everyone-reasonable Be reasonable Assume everyone is reasonable until proven otherwise, and they are open to being reminded of this. Assume unusual action is probably reasonable. Favor personal discussion over administrative action. This is the Reasonable Person Principle. [long CMU CS tradition] 43
holders-rights-privileges Align rights with responsibilities Holders of rights, privileges, and authority incur a corresponding obligation to be responsible for the outcomes of exercising those rights. [Stuff I figured out] 44
policy-changes-troublesome Don’t try to fix specific problems with sweeping policy changes – deal directly with the specific problem instead The policy changes will have troublesome side effects, and they will impose new burdens on the non-problems. [Stuff I figured out] 45
major-changes-harder Participate in early design phases Major changes get harder as design progresses. Speak up early. Stay engaged, lest your concerns get eclipsed. Waiting for the public meetings is often too late. [Stuff I learned in public advocacy] 46
stuff-figured-maybe Asking the right question is as important as getting the right answer [Stuff I figured out, or maybe Jim Horning] 47
big-tent-inclusive-computer Computer science is the study of the phenomena surrounding computers This is the “big-tent” inclusive view of computer science. The phenomena surrounding computers are rich and complex. There is, as with many sciences, a related engineering discipline. [Newell&Perlis&Simon 67] 48
appropriate-criteria-quality There are three nested classes of results: findings (fully validated research), observations (reports of facts), & rules-of-thumb (generalizations, even unvalidated, believed by investigators willing to sign them) The appropriate criteria for quality should be truthfulness and rigor for findings; interestingness for observations; usefulness for rules-of-thumb; and freshness for all three. [Brooks 88] These cards are rules-of-thumb. [Stuff I figured out] 49
itself-allen-newell Concentrate on doing great science The rest will take care of itself. [Allen Newell] 50
youre-better-particular Understand your own research strengths; choose projects where this gives you a comparative advantage If you’re a bit better than most at a particular kind of analysis or a specific domain, choose research topics where you can use that. [Herb Simon] 51
disciplines-distinguished-kinds Understand the paradigms of your field Disciplines can be distinguished by the kinds of questions they ask, the kinds of answers they accept, and their methods to find and validate answers. Software engineering does not explain this very well. [Shaw 03] [cf Schön 84 pp 191ff] 52
elements-claim-about Establish traceability between your claims and your results Show how all elements of your claim about the research are supported by the results you’re reporting and that you properly applied your methods to get the results. Don’t include irrelevant results. [Stuff I figured out] 53
passes-invokes-power Progress in programming languages can be tracked by the increasing size of programming abstractions As time passes, each line of code invokes more power. [Shaw 80] [Shaw&Klein&Ross 25] This is why “lines of code” was always a terrible measure of productivity: it measured input, not output. [Shaw 02] 54
secrets-lampson-experts Abstraction is suppressing details; good abstraction is suppressing the right details Keep secrets. [Lampson 83] Experts design elegant abstractions. [Experts 16] The key to creating a powerful abstraction is identifying the domain-related concept that is lurking in the implementation details. [Stuff I figured out] 55
including-extra-functional-properties Programming to a specification only works if you know in advance what you want ... including the extra-functional properties (aka quality attributes). Exploratory programming uses early implementations to figure out what you actually want. [Shaw 20] 56
early-program-verification The real value of formal specification and verification is taking a hard look at the code from two very different points of view In the early days of program verification we were debugging the specification as much as the code. [Stuff I figured out] 57
capture-appropriate-information Specifications are not formal, static, and complete – they are heterogeneous, evolving, and incomplete They capture the best, most appropriate information available at a given time. We call these credentials. [Shaw 96] [Scaffidi&Shaw 07] 58
classification-systems-taxonomies Seek systematic underlying structure Classification systems or taxonomies can be principled (top-down) or ad hoc (bottom-up). Both will capture domain structure; both are affected by cultural norms and politics. Both will have buckets for “other stuff that doesn’t fit.” [Bowker&Star 99] [Shaw 23] 59
generalization-makes-model Generalize just enough, but not too much Generalization makes your model useful in more cases, but it often sacrifices power for specific cases. [Stuff I figured out] Everything should be made as simple as possible, but no simpler. [attr Einstein] 60
operations-abstract-level Define the correspondence between a new abstraction layer and its implementation carefully You must show that data and operations at the abstract level are faithfully represented in the implementation. [Hoare 72] 61
walled-garden-tragedy-formal Don’t assume that formal specifications can capture everything you care about The walled-garden tragedy of formal specifications: they support, in principle, verifying things within the formal system, but they are inherently unable to specify things outside that system. You must find other ways to specify the rest. [Stuff I figured out] [Kang&Shaw 24] 62
vernacular-programmers-vastly Don’t assume programmers are highly-trained professionals with math skills Vernacular programmers vastly outnumber highly-trained professionals. They are poorly served by the software and programming languages communities. [Shaw 20] [Scaffidi&Shaw&Myers 05] 63
recall-alice-knights Distinguish carefully among the thing, the name of the thing, what the thing is called, and what the thing is Recall from Alice the Knight’s Song, and the name of the song, what the name of the song is called, what the song is called, and what the song is. [Alice 60] 64
manage-carefully-curriculum In curriculum design, the scarce resource is curriculum space Manage it carefully – curriculum design is at heart a resource allocation problem. [Stuff I figured out] [Manifesto 05] 65
certainly-course-objectives Curricula, as systems, should provide traceability from the overall objectives to the details ... certainly to the course objectives (and thence to the course content, of course) and also to other activities. This should show how overall curriculum objectives are achieved and how all required activities contribute. [Stuff I figured out] 66
enough-current-practice Teach them to think like engineers, to learn on their own, to be informed citizens ... plus enough current practice to get started. [Carnegie Plan] 67
learning-results-student Make the student responsible – there are two sides to the lectern “Learning results from what the student does and thinks, and only from what the student does and thinks. The teacher can advance learning only by influencing the student to learn.” [Simon memorial] 68
students-other-fields Help students read and study good examples before asking them to write their own Students in other fields study and critique good exemplars before creating their own. They study not just the exemplars’ appearance but also their structure, their meaning, and critiquing techniques. Programmers must likewise read and evaluate code written by others, including AI. [Shaw&Hilton&Fairbanks 26] 69
these-foundations-provide Teach enduring principles in the context of current competence These foundations provide a base for learning new technologies as they emerge. [Manifesto 05] [Carnegie Plan] 70
perlis-simplicity-perlis If you have a procedure with ten parameters, you probably missed some Perlis on simplicity. [Perlis epigrams] 71
Evidently-something-figured Creativity brings occasional disappointment Evidently, this is something that has not yet been figured out. Alas, insight on this topic is wanting. 404

To add new categories send e-mail to Roy, so that he can get the spelling right.