ABCU's CS department wanted a tool for their advisors. The idea was simple: load a file of courses, let advisors print everything in alphabetical order, and let them look up any course to see what prerequisites it needs. The real question wasn't "can you build this" but "what should you build it on." That's where the data structure choice came in. Project One had me write pseudocode and runtime analysis for three approaches (vector, hash table, BST), then pick one. Project Two was the actual C++ implementation.
I wrote pseudocode for all three structures first, then built line-cost tables breaking down how many operations each function takes per line of code. That made the tradeoffs real instead of theoretical. A vector is dead simple but searching it is O(n) and printing in order means sorting every time at O(n log n). A hash table gets you O(1) lookup, which is fast, but it still needs to collect everything into a list and sort it for the alphabetical print. A BST keeps things in order as you insert, so in-order traversal just walks the tree and you get sorted output in O(n) with no extra step.
I originally went with the hash table because the O(1) lookup felt like the obvious winner. My instructor pushed back on that. His point was that sorted output is one of the two main things the program does, and the BST handles that natively while the hash table has to work around it. He was right. I switched to BST for Project Two. That experience was actually more useful than getting the recommendation right the first time, because it forced me to weigh the operations the program actually needs instead of just picking the fastest-sounding number.
Pointer management was the recurring headache across the whole course. In the M3 linked list assignment, I had to track down a bug where removing the last node didn't update the tail pointer, which caused appends to break silently. The M5 BST assignment had the classic two-children remove case, where you find the in-order successor, copy its data up, then recursively delete the successor. Getting that right on paper is one thing. Getting it right in C++ with actual pointers is another.
For Project Two specifically, the gap between pseudocode and working code was bigger than I expected. The CSV parsing had to handle trailing commas and Windows line endings. I also needed to make sure the program gave useful error messages when someone tried to print or search before loading data, rather than just silently returning nothing.
How has your work on this project expanded your approach to designing software and developing programs?
The main thing I took from this course is to design before coding. I spent more time on pseudocode and analysis for Project One than I spent actually writing Project Two, and Project Two went smoother because of it. I also learned that your first analysis can be wrong and that's fine. My initial hash table recommendation made sense on paper, but once I weighed the actual requirements more carefully and got feedback, the BST was the better fit. Being willing to change direction based on evidence is more valuable than getting it right on the first try.
How has your work on this project evolved the way you write programs that are maintainable, readable, and adaptable?
I kept all the logic in a single file with clear separation: the BST class owns storage and retrieval, a standalone function handles CSV parsing and validation, and main just runs the menu loop. Every function has a comment explaining what it does and its worst-case runtime. If someone needed to swap the BST for a different structure later, they'd only need to replace the class and the load function. The menu code wouldn't change at all.
The other thing that stuck was writing comments that explain the "why" instead of the "what." Saying "in-order traversal produces sorted output in O(n) because the BST invariant guarantees left < current < right" is more useful to the next person reading the code than just saying "prints courses."