1/23
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
Effects of Scale
The idea that as software grows bigger and more complex, small added features can cause much bigger, unexpected problems.
Simpler is Better
A core software design principle: good software has a simple internal structure and a simple interface for users.
Internal Structure
How a program is built and organized on the inside (its code design).
Interface
The part of the software that users or other systems interact with.
Cost-Benefit Analysis
Weighing whether a new feature's benefits are worth its costs before adding it to software.
Feature Interaction Cost
The hidden cost of a new feature caused by how it affects and interacts with all the other existing features, not just itself.
Underestimating Cost
A common mistake where developers don't realize how expensive/complex adding a feature will really be.
Overestimating Value
A common mistake where developers think a new feature is more useful than it actually turns out to be.
Feature Creep (implied)
When more and more features are added, making a program more complex for both users and developers.
Security Risk from Feature Interaction
Unexpected combinations of features can create security holes, even if each feature works fine on its own.
"Attackers Break Systems, Not Components"
A security principle stating that attackers exploit unexpected interactions between features, not just single weak parts.
Secure System Design Principle
True security comes from software being modest, straightforward, and easy to understand.
Complex Design Risk
The more intricate a design and the more special-case features it has, the more room there is for errors.
Software Virtuosity
Using overly clever, intricate, or fast algorithms to solve efficiency problems; often makes code harder to maintain and less reliable.
Trade-off Consideration
Before making software more complex for performance reasons, consider simpler solutions like better hardware or reduced requirements first.
Higher-Level Programming Language
A programming language that is more abstract and closer to human language, making it easier to write and reducing bugs.
Abstraction Mechanism
A tool in a language (like procedures) that hides complex details, making code easier to read and manage.
Data Abstraction
A mechanism (like packages) that hides how data is structured, showing only what's needed to use it.
Control Abstraction
A mechanism (like iterators) that hides the details of how a process or loop works internally.
Checkable Redundancy
Extra information in code (like type declarations) that lets the compiler catch errors before the program runs.
Type Checking
A compiler process that ensures data is used correctly, rejecting code with type mismatches as illegal.
Automatic Storage Management
A feature (like garbage collection) that automatically manages memory, reducing errors from misusing memory.
Tunneling Attack
An attack that exploits vulnerabilities at a lower level of abstraction than what the software developers were working with.
Run-Time Support Library
A large set of built-in code (e.g., Ada's Run-Time Support Library) that higher-level languages rely on while running, which can itself be a target for attacks.