How I Fixed Mopac and Why It Had It Coming / The Importance of Bug Reports
November 05, 2022
One underrated habit I've picked up is informing people when problems arise in systems they maintain. I think I've acquired this habit from being a software developer, where there is a culture (at least in the free and open-source software world) of filing bug reports.
I believe this is an effective way to contribute to the community because it puts system maintainers in direct contact with their users, allowing maintainers to efficiently diagnose and resolve problems that may be common to the entire userbase.
I'll give two examples from the past few weeks.
UT Austin Prereq Portal
First is the UT prereq portal. The Office of the Registrar at UT has a student-facing portal which allows students to view the prerequisites for any course. The portal indicates which courses are "informers" (the registration system will let students register for the course regardless of its prerequisites) versus "enforcers" (the registration system will prevent students who do not meet a course's prerequisites from registering for that course). There is also a "prereq checker" (I'm not sure if it has a formal name), which allows students to select a particular course number and see if, based on their academic record / courses taken, they meet the course's prereqs. Obviously, the "prereq list" is (presumably) identical for all students, whereas the "prereq checker" provides information specific to each individual student.
The prereq checker definitely worked during my freshman year, but it's been broken for at least a couple semesters. Whenever anyone tried to check themselves, they would receive the following error message: "Please try again with a valid EID." When I first encountered the error message last year, I misdiagnosed the problem as a missing form parameter and tried to troubleshoot it, to no avail. Since then, I've sat on this bug, not knowing how to get around it.
A couple weeks ago, with the course schedule release on the horizon, I decided to email the registrar's office directly. After a little back and forth messaging to identify down the problem, they told me they reported the issue to their analysts. The next day, they emailed back to say the error had been fixed. So, all it took was a detailed email illustrating the problem, and it was fixed in a day.
Mopac Service Road and Braker Ln Intersection Eastbound Right Lane
The efficacy of bug reports is not restricted to the software world. This semester, I've been driving to the Microelectronics Research Center a couple times a week for ongoing research. My usual commute is to head west on 24th (which turns into Windsor) and then take Mopac north until the Capital of Texas / Braker Lane exit, near the Domain. Once I exit, I go straight on Mopac's service road through the Capital of Texas intersection and then make a right turn on Braker Lane, traveling eastbound for just under half of a mile before I reach the JJ Pickle Research Campus.
The northbound/eastbound traffic pattern at the Mopac/Braker intersection is a bit unusual. There are initially two eastbound lanes on Braker crossing the highway, and the right turn lane from the Mopac service road also becomes its own lane on Braker. In total, there are three lanes of eastbound traffic on Braker Ln a few hundred feet after the intersection.
Here's a rough illustration of the intersection, prior to one month ago (my memory may not be completely accurate):
On the side of the road, in place of the rhombus-shaped sign I've sketched in the bottom right corner, there is a yellow traffic sign with the same diagram -- W4-3R is its official name -- indicating an added right lane. However, this is not immediately obvious to drivers traveling eastbound, who often ignore the sign and the faded/nonexistent lane markings and end up "drifting" into the right lane (which I believe is supposed to be "protected" for the turning traffic).
I don't know how long ago the lane markings started to fade, but it was bothering me after a few weeks of driving to lab, and I also felt like it was a safety hazard. So I called the TxDOT and then Austin DOT (TxDOT wasn't sure if the intersection fell within their jurisdiction) and let them know about the problem, suggesting that simply repainting the lane markings might solve it.
When I drove to lab next week, the lane markings were repainted! Here's another illustration of the intersection, this time with the new markings:
Success! Some of the drivers still don't follow the traffic pattern, but I feel a bit safer turning right into my own new lane, now that the markings are more obvious.
Conclusions
Anecdotally, most people are receptive to bug reports because they own their products or systems and are eager to fix any problems that arise. Personally, whenever I've developed and released software (like my project for the TFA), I've always found it useful and highly constructive whenever someone can identify something I've overlooked and file a bug report (or even a feature request). The worst response a bug reporter can receive is "we know about it and we can't fix it" and the best response is an immediate or nearly immediate fix, like I witnessed in both situations.
In fact, system maintainers might have left a bug unfixed simply because they didn't know about it. The registrar's first response to my bug report was that they were unable to replicate the error, which I suspect was because staff and students might see slightly different webpages at the same link (they have admin power; we don't). Similarly, I assume people have complained about the Mopac/Braker intersection to each other, but I don't know if they ever communicated that to the road maintainers. Since the traffic department oversees so many roads, they may not have the bandwidth to actively identify individual road maintenance issues, so it seems like filing a maintenance request is the best course of action to get a direct answer.
An important qualification is that it's important not to harass people (especially free and open-source software maintainers) to fix their systems. Rather, sending a single detailed bug report, either via email, through a form, or over the phone, is the best course of action. From the system maintainer's perspective, it is often helpful to have a ticketing system to keep track of these bug reports, so users don't grow anxious that their problem is being ignored. Another simpler solution is doing what the registrar did, emailing me to first diagnose the problem and then keeping me updated as it was sent to the development team and then resolved.
To be clear, while I think I contributed to the prereq system being fixed, I don't know how big a role I played in fixing the road. There was indeed a correlation between when I called the Ds of T and when the problem was resolved, but I might have been one of many bug reporters, and they may have already chosen that particular time to repaint the markings. Regardless, I think it's important to not fall to this sort of bug reporting bystander effect, where system users don't file bug reports because they assume someone else will or has already filed one.
I am hopeful that these two bug fixes described above will benefit a large number of people. With that in mind, I look forward to identifying more bugs and helping maintainers keep their systems running smoothly.