One common mistake is deviating from the original design without justification, which can lead to a misaligned or incorrect implementation. This often occurs when students rush to code or misunderstand the purpose of the design phase. Another frequent error is overcomplicating the solution—adding features or logic not specified in the design, which introduces unnecessary complexity and potential bugs. Students may also neglect to fully implement all components of the design, especially if it includes multiple modules or interacting components. To avoid these issues, students should carefully review the design before starting, annotate it if needed, and tick off components as they are implemented. Maintaining traceability between the design elements and the code modules is key. Using a checklist or development log can help. Additionally, continually comparing the developing code against the original specification helps ensure fidelity. Finally, if changes are made, they should be documented with clear reasoning and tested accordingly.

User feedback can and should be gathered during implementation by involving potential users in early prototyping and iterative development cycles. One effective method is using incremental development, where parts of the program are implemented and tested in stages, allowing for user input between versions. Low-fidelity mock-ups or clickable prototypes can be shared early on to test layout and basic functionality. Regular usability testing sessions can be scheduled at predefined milestones, during which users interact with in-progress builds and provide structured feedback. This feedback should be documented and categorised (e.g. usability issue, functional gap, enhancement request) so it can be prioritised accordingly. Bug tracking systems or feedback forms allow users to submit observations in real time, which can then be reviewed by the development team. Integrating this feedback during implementation avoids last-minute overhauls, reduces the risk of misalignment with user expectations, and results in a more polished and user-centred final product.

Test-driven development (TDD) is a methodology where developers write tests before writing the actual code. The process follows a strict cycle: write a test that fails, implement the minimum code to pass the test, and then refactor. Although more commonly used in professional environments, TDD is suitable for A-Level projects, especially when working with modular designs or class-based structures. It encourages a strong focus on requirements and forces the programmer to think through the expected behaviour before implementation. TDD supports correctness, early detection of bugs, and makes future refactoring safer, as developers can be confident that changes do not break existing functionality. For A-Level students, applying TDD in small-scale modules can significantly improve code reliability and confidence in test coverage. It also encourages good documentation habits, as each test effectively documents expected outcomes. While full adoption of TDD might be ambitious, applying its principles to key components is both beneficial and feasible.

Handling code dependencies and interactions between modules is critical for creating robust and scalable software. First, students should ensure that each module has a clearly defined purpose and a limited scope—this supports separation of concerns. Interface design is essential: modules should interact through well-defined inputs and outputs, ideally using function or class interfaces rather than direct data access. Documentation of expected inputs, outputs, and side effects helps prevent confusion. Dependency management means ensuring that changes in one module do not unintentionally affect others. This is supported by avoiding global variables, using encapsulation (in object-oriented programs), and employing dependency injection where appropriate. Furthermore, unit testing each module independently verifies its correctness before integrating with others. When modules are combined, integration testing is required to confirm that they interact correctly. Keeping modules loosely coupled and highly cohesive is a key principle. Using a dependency diagram or module map can help students visualise and manage these relationships effectively.

Effective codebase structure is essential for managing complexity and enabling ease of navigation, especially as a project grows. Students should begin by organising their code into directories or folders based on functionality—such as separating input/output handling, core logic, data processing, and user interface code. Each file should ideally contain only one class or a small group of related functions. File names should be descriptive, e.g. fileHandler.py or userInterface.java. Comments and headers at the top of each file should explain its purpose and any dependencies. Configuration files (e.g. settings or constants) should be stored centrally, and resource files (like images or text) should be in their own dedicated folders. Using a main driver file (e.g. main.py or App.java) to initialise and link the modules gives a clear entry point. When working with object-oriented languages, grouping related classes into packages or modules improves maintainability. Good file structure also supports version control, deployment, and collaboration.