GK One-Line Question & Answer

Premature optimisation prioritises performance over correctness and maintainability without profiling data — Knuth's rule applies; optimisation is legitimate after profiling identifies actual hotspots

Asserts document and enforce invariants about program's internal state; should not validate external inputs because assertions are typically disabled in production builds allowing invalid inputs to pass unchecked

McCabe's metric counting linearly independent paths: M = E - N + 2P; complexity above 10 indicates code difficult to test and maintain — should be refactored into smaller units

White-box tests based on code structure cannot detect missing functionality; black-box tests cannot ensure structural paths are exercised; both alone are insufficient

Quality and sensitivity of the test suite by introducing deliberate faults (mutations) and measuring whether tests detect them — a suite with high coverage but weak assertions will fail to kill many mutants

The same set of tests run repeatedly stops finding new defects because surviving code has been adapted to pass those specific tests — remedied by regularly reviewing and augmenting the test suite

Values at the edges of equivalence partitions (exact boundary, one below, one above) because defects cluster at boundaries due to common off-by-one errors

TDD's Red-Green-Refactor cycle writes tests before code; beyond defect reduction it forces testable design (high cohesion, low coupling, DI) because untestable code cannot pass tests written before implementation

Alpha testing is conducted at the developer's site by internal users in a controlled environment before beta; beta testing is then by selected external users in their real-world environments

A logical memory leak occurs when objects are still referenced (preventing GC) but no longer needed — common causes: static collections holding objects, event handlers not unregistered, and caches without eviction policies

Running a program with symbolic rather than concrete inputs, tracking path conditions — enabling automatic test case generation and bug finding; limited by path explosion (exponential path count as branches grow) and constraint solving complexity

Correctness depends on relative timing of concurrent operations; non-determinism makes them hard to debug because failure may not occur on every execution, disappears under debugging, and manifests only under specific load patterns

A proactive fault management technique that periodically restarts, cleans, or reinitialises software to prevent accumulation of internal state degradation before failure occurs

Multiple compounding challenges: missing documentation, loss of developers' tacit knowledge, obsolete technologies, accumulated technical debt, tightly coupled architecture, and business criticality limiting testing windows

Software quality degrading over time due to: 1) accumulation of internal failures (memory leaks, resource fragmentation) and 2) structural degradation (accumulated technical debt making future changes harder)

Technical debt refers to suboptimal original design decisions; maintenance debt accumulates through deferred maintenance activities — known fixes, updates, improvements postponed and becoming increasingly expensive as dependencies change

The cognitive process of understanding existing code well enough to modify it safely; consumes 50-60% of maintenance effort because code was not written to be understood — names are ambiguous, logic implicit, and decision rationale absent

At level 2 processes are project-specific and repeatable; at level 3 processes are organisation-wide, standardised, and defined — enabling consistent performance across all projects

Adding manpower to a late software project makes it later — because new developers require training time from existing developers and increase communication overhead

Incremental delivery adds functionality in planned chunks without revisiting prior increments; iterative development repeatedly refines the entire system through cycles, improving quality with each iteration

A family of related systems that share a common, managed set of features satisfying specific market needs — enabling systematic reuse of architecture, components, and assets across multiple products

Reliability is the probability the system will perform its required function without failure for a specified time period; availability is the proportion of time the system is operational and accessible when needed

Architecture describes the high-level structure of a software system — its principal components, their relationships, and the fundamental principles governing their design; design elaborates the internal details of individual components

Non-functional testing verifies quality attributes like performance, security, and usability rather than specific behaviours; it often requires the entire integrated system under realistic load and cannot be decomposed into unit tests

An error is a human mistake producing a fault (defect) in code; a fault is the static defect; a failure occurs when the fault is executed and the system behaves incorrectly

A test oracle is the mechanism determining expected output to compare against actual results; the oracle problem is that for many complex systems no reliable oracle exists to determine correct output

Divides input data into classes where members are expected to cause identical behaviour — testing one value per class is assumed equivalent to testing all values, reducing redundant tests

Re-executes tests after changes to ensure previously working functionality has not been broken; inadequate regression testing allows regressions to reach production where detection and repair cost is highest

Testing finds that a defect exists; debugging locates and understands the defect so it can be fixed — debugging begins where testing ends

A defect that disappears or changes behaviour when you attempt to observe or debug it — commonly caused by timing-dependent race conditions that the debugger's pausing alters

Explaining code step-by-step to an inanimate object; the act of articulating the problem forces explicit processing revealing the solution — exploiting the principle that verbalisation activates different reasoning pathways

Two or more threads permanently blocked waiting for each other; Coffman conditions: mutual exclusion, hold and wait, no preemption, and circular wait — all four must hold simultaneously

Systematically halves the search space by inserting diagnostic checks at midpoints to determine which half contains the fault — most effective when fault location is unknown in a large codebase or long sequence of operations

Analyses a program's state after it has crashed or terminated abnormally, relying on core dumps, crash logs, exception stack traces, and memory snapshots captured at the moment of failure

Automatically minimises a failure-inducing input to the smallest possible failing case — solving the problem that bug reports contain complex large inputs where only a small portion causes the failure

Corrective fixes defects; adaptive modifies for changed environments (new OS, hardware, laws); perfective enhances functionality or performance beyond original requirements

Unintended propagation of changes where modifying one component requires changes in dependent components; minimised by low coupling, information hiding, stable interfaces, and encapsulation

Extracting higher-level abstractions from existing code when documentation is missing — unavoidable when maintaining legacy systems where only source code or compiled binaries survive without specifications

Restructures existing code to improve internal quality without changing observable external behaviour — the key constraint is that functionality must remain identical before and after

Incrementally replaces a legacy system by routing new functionality to a new system while the old system continues running — solving the problem of 'big bang' replacement requiring everything ready before switching