WGU D493: Scripting and Programming - Applications

Scripting and Programming - Applications: the C++ course, decoded

WGU D493, Scripting and Programming - Applications, is a hands-on programming course in the School of Technology. It is the current course code for what many students still call C867, and if you dug up an older guide that told you this class is about Python, set that aside now: D493 is a C++ course. You will read, write, and debug real C++ code, and you demonstrate what you have learned by building and submitting a complete program rather than by sitting a multiple-choice exam.

Direct answer: You pass D493 by writing one working C++ program to a detailed rubric, not by memorizing facts for a test. Work through the C++ material until you are comfortable with classes, arrays, and pointers, then build the assigned student roster program step by step, testing every function against the required output before you submit.

Most students meet D493 early in a technology degree, often right after an introductory programming course. It matters because it is where object-oriented thinking becomes concrete: you stop writing loose scripts and start designing programs out of classes and objects that talk to each other. That skill carries directly into later courses like D284A Software Engineering and D387 Advanced Java, so the effort you invest here pays off well beyond the transcript.

What you actually submit: the performance assessment at a glance

D493 is a performance assessment (PA). There is no objective exam to schedule and no proctored multiple-choice test. Instead, you receive a scenario in which you act as a contractor building a program to manage a roster of students, and you submit source code plus supporting files for an evaluator to grade against a rubric. Based on publicly shared project descriptions, the work centers on these areas:

• Classes and objects. The current version uses a base Student class with degree-specific subclasses and a separate Roster class that holds and manages the collection of students.
• Inheritance and encapsulation. Shared student data lives in the base class; specialized behavior lives in the subclasses. Access to fields is controlled through accessors and mutators.
• Arrays and pointers. Student records are stored and manipulated using arrays and pointers, and you are expected to manage memory responsibly.
• Parsing input data. You take an array of student data strings and break each one into its individual fields to populate objects.
• Required functions. The rubric specifies methods your program must implement, typically including adding and removing students, printing the full roster, printing students by degree program, flagging invalid email addresses, and computing average days to complete courses.
• Enums and data types. A degree-program enumeration and correct use of C++ data types are part of the specification.
• Clean, documented code. Comments, sensible naming, and output that matches the expected format exactly all factor into evaluation.

The single most important habit here is to treat the rubric as your checklist. Every requirement it lists is a place you can earn or lose credit, so read it before you write a line of code and keep it open the entire time.

How hard is D493, really?

Honest answer: it depends heavily on your prior coding experience. Many students report that if you already program comfortably in another language, D493 feels approachable and can be finished in roughly two to four weeks. Students who are newer to programming, or new to C++ specifically, more often describe needing six to eight weeks and say the pointer and memory concepts are the steepest part of the climb.

Because there is no exam to cram for, difficulty is less about volume of material and more about precision. The program either compiles and produces the required output or it does not. That can be frustrating early on, but it is also fair: once your code works and matches the rubric, you are done. Budget focused build time rather than passive reading time, and give yourself a cushion so an evaluator's feedback does not catch you at a deadline. If C++ syntax itself is new to you, reviewing foundational programming logic from a course like D335 Introduction to Programming in Python can help the underlying concepts click even though the language differs.

A build plan that actually works

Passive rereading is the slowest path through a coding course. Use active, project-driven study instead:

1. Week 1 - learn the language, then prove it. Work through the assigned C++ material (the course typically uses an interactive text with embedded exercises). Do not just read the examples; retype them, change them, and predict the output before you run it. This is active recall applied to code.
2. Week 1-2 - master the hard parts in isolation. Write tiny throwaway programs that do one thing: a class with a constructor, an array of objects, a pointer that you allocate and free, a function that splits a string. Getting each concept working alone is far easier than debugging it inside the full project.
3. Week 2-3 - build the roster program incrementally. Start with the Student class and its accessors. Confirm it works. Add the Roster class and the ability to add and print one student. Confirm it works. Add each required function one at a time, testing after every addition. Never write three features and then try to debug all of them at once.
4. Ongoing - test against the expected output. Practice testing is your best friend here. Run your program after every change and compare its output character by character to what the rubric describes. Small formatting differences are a common reason for a returned submission.
5. Before submission - reread the rubric line by line. Space this out: review it at the start, at the midpoint, and again just before you submit. Each pass catches requirements you glossed over the first time.

Use a real development environment such as Visual Studio Community so you get a proper compiler, debugger, and error messages. Learning to read compiler errors is a skill in itself, and it will save you hours.

Where students lose points

Most returned D493 submissions come back for avoidable reasons, not deep conceptual failures:

• Ignoring exact output requirements. If the rubric says a line should read a certain way, matching it "close enough" is not enough. Copy the required format precisely.
• Skipping a required function. It is easy to build the impressive parts and forget a small mandated method. Check every listed function off the rubric individually.
• Memory and pointer mistakes. Forgetting to free allocated memory, or mishandling pointers, produces bugs that are hard to see. Address this early rather than patching it at the end.
• Forgetting personalization steps. Some versions ask you to print your own name and student ID or include specific identifying output. Do not omit these small but graded touches.
• Poor or missing comments. Readable, documented code is part of the evaluation, not an optional nicety.
• Not using version control. Saving working checkpoints as you go prevents a broken change from wiping out hours of progress. If commits are new to you, D197 Version Control covers the workflow.

One more caution: because completed versions of this project are floating around online, it can be tempting to lean on them. Don't. Submitting work that is not your own is an integrity violation, and just as importantly, you will not learn the material you need for later courses. Use examples only to understand a concept, then write your own solution.

D493 Readiness Checklist

Before you submit, confirm you can honestly say yes to each of these:

• Can you define a C++ class with private fields, and read and write them through accessors and mutators?
• Can you create an array of objects and loop through it to display each one?
• Can you allocate memory with a pointer and free it correctly when you are done?
• Can you take a string of comma-separated data and split it into individual fields?
• Can you implement every function the rubric requires, including the printing and calculation methods?
• Does your program compile with no errors and produce output that matches the required format exactly?
• Have you included your required identifying output, comments, and any personalization the rubric asks for?
• Have you tested each function individually rather than assuming the whole program works?
• Have you reread the full rubric one final time against your finished code?

D493 FAQ

Is D493 an objective assessment or a performance assessment?

It is a performance assessment. You submit a complete C++ programming project for evaluation against a rubric; there is no multiple-choice exam to schedule or proctor.

What programming language does D493 use?

C++. If you find an older guide claiming the course is about Python, it is out of date or simply incorrect. Set up a C++ development environment such as Visual Studio Community before you begin.

How long does D493 take to complete?

It varies with experience. Many students with prior programming background report finishing in roughly two to four weeks, while those newer to coding or to C++ more often describe needing six to eight weeks. It is a build-time course, so plan focused hands-on sessions rather than reading time.

Do I need to know C++ before I start?

No, but the course moves faster if you already think in code. The assigned material teaches the C++ you need. If general programming logic is still new, reviewing an introductory course first makes the concepts easier to absorb.

What is the project I have to build?

Publicly available descriptions indicate you build a student roster program: a set of classes that store student records, parse input data, and implement required functions such as adding and removing students, printing the roster, filtering by degree program, flagging invalid emails, and calculating average completion days. Follow your official course rubric, which is the authoritative specification.

Can I resubmit if my program is returned?

Performance assessments at WGU are designed around evaluator feedback and revision. If your submission does not meet every requirement, you receive notes on what to fix and can address them and resubmit, which is exactly why submitting early is worth it.

For the full spec, always defer to your official course materials. You can review WGU's technology degree offerings on the WGU IT programs page. For more independent study guides, browse the School of Technology hub or the complete index of WGU course guides.