An expensive line of code

I was talking to my dad today, he told me that the first computer he bought had 128MB of hard drive storage and we laughed. It cost more than a MacBook today. In 2001 a friend told me his sister who just started college bought a laptop that had 14GB of storage and I asked him "What is she going to do with all that space?". After all, that much space was expensive at the time.

In computer science when we talk about something being expensive we are talking about lines of code that consume a lot of computer resources (memory and processing power). It is easy to forget computer resources are limited these days. My Smile internet is unlimited, the desktop I type this post on has a 1TB hard drive, it has 12GB of RAM and has 4 Cores, although this is a bit excessive, it is not too far from any typical machine today, computer resources are no longer scarce. But this is not the kind of expensive I am talking about in the story I am going to tell today.

This summer I was on vacation in Denver staying with Ben. He is the VP of Engineering of a hot startup in Denver. is a dating site for people who are into a healthy lifestyle, self-awareness, spirituality etc. So I got to hear awesome startup hustle stories. One of the features of the site is an algorithm that suggests people to you that they think you would get along with and the suggestions show up on your feed. This feed is critical in facilitating engagement on the site, it exposes the new sign ups to the older members and allows members to discover each other.

In the initial creation, there was an oversight. The query that pulled the profiles for the feed ordered the profiles in Descending order of when the users were last active (Recently active first). Postgresql the database they are using has a quirk or a feature depending on how you look at it. Records that are NULL (empty) in the field that you are sorting by appear first when they are ordered in Descending order. This caused the feeds for some people to stay the same. This is bad because without variety in the feed, people will interact less and less over time. To exacerbate this issue, the people who had an empty last active timestamp were people who never finished signing up. So users were getting people in their feed that would never go away and also will not respond if they tried to engage with them, thereby reducing a lot of interaction on the site.

Upon being notified of this problem Ben fixed it in minutes and pushed the code, he went to work that morning and alerted the team about what had happened and told them "Everything is going up" Engagement metrics, messaging, likes and so on... and it did.

The very next day they broke their record for most money generated in a single day and it went up from there. As predicted the site just became more lively and the interactions continued to grow. It got me thinking, how much money... actual cash has been lost between the inception of the problem and the fix. The good news and the bad news is that they will never know. I am always fascinated about how thin the line is between an app that cannot start and one that does, an app that frustrates its users and one that delights its users and in this case how thin the line was for a difference in the revenue.

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent" - Prof. Edsger Dijkstra (On the cruelty of really teaching computer science)

Every line of code is a potential liability, every line we write costs us on multiple levels. Some cost more than others. As developers, it is easy to only think of computer resources when we write lines of code and forget that a line of code can be expensive in other ways too.