ACM-SW common mistakes
ACM-SW · Understand the traps and how to avoid them.
Choosing a design pattern by matching its name to a keyword in the scenario (e.g., picking Singleton because the word 'single' appears) rather than by verifying the forces the pattern resolves actually exist.
Candidates memorise pattern names and intent statements but never learn the problem each pattern addresses, so surface keyword matching feels sufficient under time pressure.
What to do instead
For each candidate pattern, write one sentence naming the specific problem it solves and check whether the scenario exhibits that problem (e.g., 'multiple interchangeable algorithms selected at runtime' for Strategy) before selecting.
Treating requirements statements as testable without checking for vague qualifiers, and then accepting a test case that merely rephrases the requirement.
Candidates focus on whether a requirement is 'reasonable' rather than whether it is verifiable, and they confuse restating a requirement with designing a test that would fail if the requirement were unmet.
What to do instead
For each requirement, produce at least one concrete input/expected-output pair; if the requirement uses words like 'fast', 'user-friendly', or 'appropriate', flag it as untestable and state what measurable criterion is missing.
Confusing unit, integration, system, and acceptance test levels, and assigning a test to the wrong level (e.g., placing an end-to-end business workflow under unit testing).
Level definitions overlap in casual usage, and candidates classify by the size of the feature being tested rather than by what is under test and what is stubbed or real.
What to do instead
Classify by scope and isolation: unit tests exercise one unit with collaborators replaced; integration tests exercise interaction between real components; system tests exercise the whole system against requirements; acceptance tests confirm fitness from the user's perspective.
Selecting a maintenance category by the symptom described rather than by the trigger for the change (e.g., labelling a performance improvement as corrective because it was reported as a bug).
Candidates equate 'something is wrong' with corrective maintenance and overlook that adaptive, perfective, and preventive categories are defined by intent, not by whether a user complained.
What to do instead
Ask what prompted the change: a defect against existing requirements (corrective), an environmental change such as a new OS or regulation (adaptive), improving quality or adding capability with no defect (perfective), or forestalling future problems such as refactoring or adding tests (preventive).
Assuming a version control branch-and-merge strategy or a CI pipeline solves a coordination problem, when the question is about change control, baselines, or configuration auditing.
Candidates collapse all of configuration management into 'use Git', so any question mentioning versions or releases gets answered with branching advice regardless of whether the issue is identification, control, status accounting, or audit.
What to do instead
Map the scenario to one of the four CM functions (identification, control, status accounting, audit) and name the artefact and control point (e.g., baseline plus change control board approval) before answering.
Recommending a heavyweight process (full waterfall with exhaustive documentation) for a small, volatile, low-risk project, or the reverse, without weighing the project's characteristics.
Candidates anchor on one preferred lifecycle model and treat process selection as a values question rather than a risk- and uncertainty-driven decision.
What to do instead
Explicitly weigh requirement stability, team size and co-location, regulatory or safety criticality, and delivery cadence; justify the chosen model by naming which of these factors it addresses.
Answering ethics items with what is legally permissible or what protects the employer, instead of applying the profession's obligations to the public interest and the duty to report.
Candidates import workplace loyalty norms and legal-minimum reasoning, and they have not internalised that professional codes rank public safety and honesty above organisational convenience.
What to do instead
Apply a fixed priority order: public safety and welfare first, then honesty with the client and employer, then confidentiality; when these conflict, the correct action is to escalate through proper channels and document, not to stay silent or to leak publicly as a first step.
Confusing cohesion and coupling, or assuming low coupling always means good design, without noticing that a solution traded coupling for poor cohesion.
The two terms are taught together and are easy to swap; candidates also treat each as a pure good rather than as forces to balance, so they miss options that improve one and damage the other.
What to do instead
Define cohesion as how strongly related the responsibilities inside one module are and coupling as how much one module depends on another's internals; evaluate each proposed option against both axes and prefer high cohesion with low, explicit, interface-based coupling.
Treating code-level refactoring, defensive coding, or code review as substitutes for design-level decisions, and answering construction questions with design or process answers.
Domain boundaries blur in practice, and candidates default to the technique they know best rather than the domain the question targets.
What to do instead
Before answering, identify the decision level: architecture/design (structure and interfaces), construction (implementation technique, standards, idioms), or process (review, metrics); pick the technique that operates at that level.
Reading a metrics or quality question as 'more testing is better' and ignoring that defect-detection effectiveness depends on where defects are injected and what the metric actually measures.
Candidates hold a general belief that testing is the main quality lever and do not distinguish detection phase from injection phase, or process metrics from product metrics.
What to do instead
For each metric question, state what it measures, what it cannot tell you, and which phase it informs; recognise that defects found late are usually injected earlier (requirements and design), so prevention and early review matter alongside test coverage.