Why C950 Stalls People for Months: Vague Requirements and the Two-Task Split

C950 is a performance assessment course, so there is no exam to cram for and no proctored deadline forcing your hand. Task 1 is a planning document with pseudocode and complexity estimates. Task 2 is the working WGUPS routing program in Python plus a written report. That structure sounds generous until you notice it removes nearly every external deadline from the hardest project in the degree.

The requirements document takes several passes to parse, and students frequently report that most of their lost time happens before a line of code gets written. A common sticking point is the phrase "self-adjusting data structure," which many people read as a directive to build something far more elaborate than the rubric asks for. A hash table with a reasonable collision strategy satisfies it, and instructors often confirm as much during cohort sessions.

Students who break the project into milestones tend to finish in a few weeks, while those who treat WGUPS as one giant assignment often sit on it for months. One early step helps more than any tutorial: book a meeting with a course instructor before you feel stuck, since calendars are often more open than the scheduling portal suggests.

Build the Hash Map From Scratch Before You Touch Routing

The core requirement is a self-implemented hash table for package storage, and Python's built-in dictionary cannot serve as that structure. Dictionaries remain fine for the distance table and general program plumbing, so the restriction is narrower than it first appears. Some students report passing with a plain dict, but the consistent advice from retakers is to build the table yourself rather than gamble on how a given evaluator reads the rule.

Collision handling is the part that trips people up. Separate chaining and table resizing are both accepted, and chaining is the lower-risk choice because it is easy to implement and easy to explain in the write-up. ZyBooks covers this chapter well, and the widely cited Joe James hash table walkthrough is the video students credit most often.

Get insert, lookup, and update working against the raw package data before routing exists at all. Debugging a hash table and a routing algorithm at the same time is where projects stall.

Greedy vs. Nearest Neighbor vs. Dijkstra: Picking a Route You Can Defend

Nearest neighbor is the community default for a reason: it is short, readable, and reliably lands under the 140-mile constraint. Dijkstra and brute force implementations both show up in passing threads, so understand the tradeoffs well enough to justify your choice in writing, not just to code it.

Hardcoding which packages go on which truck is widely reported as acceptable. Hardcoding the delivery order is not, since the algorithm still has to sequence the route itself. Before submitting, map your addresses visually and confirm total mileage, because the rubric rewards a working, clearly explained solution over an optimized one.

Time Is Just Distance: Clocks, Statuses, and the Special-Constraint Packages

The reframe that unblocks most people is simple: nothing is actually moving and no time is actually passing. Mileage converts to minutes, and delivery times get recorded as the route runs. Students report using datetime and timedelta for departure and delivery times, though plain floats converted for display work

1 · BUILD THIS BEFORE ANY ROUTING packages.csv run your parser on it Your own hash table insert · lookup · update · chaining a plain dict is not accepted here separate chaining is the low-risk choice distance.csv address lookup table Distance lookup the restriction is narrower than it looks a plain dict is fine for this one get insert and lookup working first 2 · ROUTE Nearest neighbor per truck hardcode the truck assignment: OK the algorithm must sequence the stops Cumulative mileage must land under 140 miles map the addresses before submitting 3 · TIME, STATUS AND THE MENU miles → minutes nothing is actually moving datetime · timedelta departure and delivery Status at time T a comparison, not a table read CLI menu ID · all statuses · mileage Debug the hash table and the routing separately — doing both at once is where projects stall.
Figure 1. The C950 build order: a self-implemented hash table for the packages, a plain dictionary for the distance table, nearest-neighbor routing under 140 miles, then mileage converted to minutes for the status logic.

The Command-Line Menu: What Evaluators Actually Check

The interface does not need to impress anyone. A plain text prompt that prints results passes, and students consistently report that visual polish earns nothing extra. What matters is that the menu does the three things the rubric names: look up a package by ID, print every package status at a given time, and report total mileage with the route.

Tell the user on screen which time format you expect. A prompt reading "enter time in military format (HH:MM)" heads off the input questions that get submissions returned. Keep the status logic honest as well. Package status is a comparison between the time the user enters and the recorded delivery time, not a value read straight out of the hash table.

Screenshot discipline saves a full rewrite. Capture the exact runs the rubric asks for, at the exact times it specifies, before you begin drafting the report. Whether you keep everything in main.py or split the program across files is purely preference here, unlike Software I and II.

The Space/Time Complexity Write-Up: Where Most First Submissions Get Returned

Most C950 returns happen in the document, not in the code. Evaluators grade against the rubric line by line, so paste the rubric statements into your document as section headers and answer each one directly. Highlighting the lines you have not addressed yet keeps you from missing any.

Put your complexity analysis in a table, one row per major function, with time and space listed side by side. A common approach is to analyze the six or so largest functions and then report the total using the highest complexity found among them rather than summing every value into a messy result.

Comments are graded, and function-level docstrings alone are not enough. Students report being returned for lacking inline comments that explain individual components inside each function. Track the sources you learn from as URLs in your code comments while you build, then convert them to APA citations at the end. Expect redundancy between the code comments and the written analysis, and repeat yourself freely when the rubric asks the same question twice.

An Actionable 7-Step Milestone Routine to Finish C950 in Under 2 Weeks

  1. Read the requirements and rubric twice, then rewrite every rubric line as a checkbox in a single document. Do this before opening an IDE.
  2. Book a course instructor meeting and watch the "Getting Greedy, Who Moved My Data" webinar. Skim Course Chatter for recent version changes.
  3. Build the hash table alone, then test insert, lookup, and update against raw package data.
  4. Convert the package and distance spreadsheets to CSV, parse them, and build your distance lookup.
  5. Implement nearest neighbor per truck, track cumulative mileage, and confirm you land under 140 miles.
  6. Add the time simulation, package statuses, and CLI menu, then capture every required screenshot.
  7. Write the report straight down the rubric headings, check each box, and submit early since revisions cost nothing.

Resources worth keeping open: the Joe James hash table video, the "Getting Greedy" webinar code from Supplemental Resources, your course instructor's study guide, Python's datetime and csv library docs, and the WGUPS walkthrough repos on GitHub for reference only, since copied code gets returned for originality.

References

Sikandar Ali - Academic Consultant
Written by Sikandar Ali

Sikandar Ali is a skilled academic consultant with expertise in research methodology and essay structure. With over 10 years of experience, he helps students develop critical thinking and writing skills for academic success.