I recently had to do a deployment for a client demo. On local everything worked fine. All the tests were passing. All the data was where it was supposed to be. And then I pushed it to production. Suddenly, queries were failing. And I could not figure out why. So I fixed the first query. Re-built it, pushed again. It worked, but another thing broke. Rinse repeat and another thing broke.
All the queries that were failing had something in common. An error because a function was receiving nil or an empty enumerable. They were built for when data to be queried existed. But in production, I had no data. I was working with an empty state. I had spent the past week designing for when the data is already there. Designing for when my database is already seeded. Designing for when queries were passing. But prod will get a blank slate. I was a bit angry and a bit embarrassed at myself for overlooking such a situation.
It reminded me of old developer wisdom I had heard before.
80% of the time in software development is about discovering and covering the "unhappy" paths.
source: https://x.com/sihui_io/status/914908896371777536?
While I am not sure about that metric, the point stands.
So now I have had to re-orient my process for writing new features. I have to define all possible states that the feature may be in and test all the states. That way I do not have to spend another 6 hours going through production wondering why that query is failing. It is good to assume failure and the unhappy path. Because then you can plan for it.
Top comments (0)