Fumigation
There’s always an inexhaustible list of features, user requests, great ideas, and random goodies we would like to implement at Expensify. However, for the past few weeks we froze 99% of new feature development. Instead, this milestone we took a step back and tackled the most dreaded part of any engineering task: Bugs. That’s right, we voluntarily decided to take on the infinitely scrolling list of alerts, warnings, crashes, plunks, thunks, and uglies — and fix them all.
But why would we take a break from making the product bigger? Because first we wanted to make the product better. We wanted to get rid of all that code that was causing unexpected glitches or unacceptable results. The bugs were just plain annoying, both to us and to our users.
Bugging Around
Bugs come in all shapes and sizes. There were big bugs, little bugs, confusing bugs, convoluted bugs, old bugs, new bugs, obscure bugs, scratch-your-head-and-say-wha? bugs. But we tackled them all. I’ve asked the Engineering team for their thoughts. Here are the highlights from this season:
What was most significant/important/enjoyable bug you fixed this milestone?
The most fun one was moving database checkpointing into a different thread so our systems don’t occasionally halt for a second or two slowing down the site. But, really I imagine the one I’m enjoying most now was probably some trivial thing that reduced the number of my daily alerts from 9182739821731982739821 to just 123098218093.
–Witold
I fixed the iPhone app from crashing due to low memory.
–Tom
[Some engineering mumbo-jumbo… in sum, Nate] effectively eliminated the software constraints on the size of PDFs we can make.
–Nate
Fixing small bugs that made a big difference, and fixing things that never worked in the first place. For example, detecting the file extension when uploading receipts before we try to upload the receipt to the server and make it crash.
–Mich
How did you feel about this milestone?
[I enjoy the] fewer emails bugging me about junk. I no longer have 500+ emails each morning.
–Witold
People don’t like things that crash.
–Tom
I did not enjoy working on high bugs because I am a terrible tester and it would take me a very long time to reproduce many of these errors. However I do like the fact that my ToDo list is much much shorter than it used to be.
–Nate
Frustration: how do you reproduce something that is not supposed to happen? Relief: our big red bug count on the dashboard is not a number divisible by 100.
–Mich
Why was this milestone important? What did you get out of it?
[We now get] faster detection of new bugs.
–Witold
The product has become much more stable as a result of our focus on the bug hunt, and I think this will lay the groundwork for future required levels of excellence. Before, each new high bug was a drop in the bucket. Now it will be more like a gong at a funeral procession.
–Nate
The code is much cleaner now, so my OCD isn’t triggered everytime I look at it.
–Mich
Now that our Critical and High Bug count is approaching zero, the Engineering Team is experiencing a mix of feelings. It’s not that we were particularly attached to these bugs, or we’re going to miss them or anything. It’s more of a fresh, clean start feeling, a blend of nervousness and excitement for what comes next. It’s time to stop looking at old code and start creating new one.
May all those bugs rest in peace.
