Uncovering and fixing bugs here at YNAB is kind of like an episode of Law & Order…but more like if Law & Order was done using webcam footage and it was just people thinking a lot and typing and clicking on things on their computers. But I would argue that some of the bugs we find and fix are just as intense as some of the crimes that they solve on Law & Order.
In the YNAB bug-fixing system, YNABers are represented by two separate, yet equally important groups: the Support Specialists who investigate potential issues and the Developers who
prosecute fix the bugs. These are their stories:
- We tracked down an interesting bug that seemed to haunt us from our past. Our sleuthing Support Specialist, Robert, uncovered a doozy: When editing a Build Your Savings / Target Balance (By Date) or a Plan Your Spending / By Date goal that has a target date in a prior year, YNAB would not display that year in the year dropdown, but instead pre-select the current year. Brady, threw the book at this bug and we were able to fix this issue for good. Sweet justice.
- It was a cold Tuesday morning in January. Nothing seemed too out of the ordinary. Just another day of helping YNABers gain total control of their money in the YNAB Support Queue™. Suddenly, a bug. Robert stepped onto the scene of the
crimebug to find that YNAB was accidentally closing modals if a user clicked within it, dragged their mouse outside of it and let go. With all of the evidence of this bug that had been brought to light, our hard-nosed Developer, Kyle made short work of this nasty bug. YNAB now only closes the modal if the user explicitly clicks outside the modal to close it. We rest our case…meaning we closed the issue in GitHub, but still.
- On an undercover assignment (it was cold that morning, so he had a blanket) our Support Specialist, Dan found a small trace of users getting stuck while going through the welcome onboarding flow in YNAB. “Put on another pot of coffee. This may take awhile, team” Dan uttered. After extensive research set to an ominous music montage, he found that If a user set a filter or specified a search before completing the “Schedule a Transaction” onboarding step, they could get stuck on this onboarding step. Brady, our Developer, found that this bug couldn’t handle the truth, and put this bug away for life (I realize that the “A Few Good Men” quote has very little business being in this Law & Order fan-fiction, but it seemed appropriate).
We’ve added some validation for
payee_name when creating or updating a transaction through the API. The
payee_name can no longer begin with any of the following: (Transfer* :, Starting Balance, Manual Balance Adjustment, Reconciliation Balance Adjustment). This may seem like a bummer when you’re buying a gymnastic balance beam from your favorite store, “Starting Balance,” but we have to draw the line somewhere.
*Note: While we will allow a
payee_name beginning with the word “transfer” (or “Transfer”), we won’t allow it if it is followed by “ :” (i.e. “Transfer :”). This is to differentiate it from our standard transfer items.