Why are Software Updates Incredibly Difficult.

Have you ever wondered why it’s so hard for a software company to add just one feature, and why it takes so much time? When I started working in YouTube Shopping team, I often felt this way. Whenever clients asked us for a new feature, it always took us a long time to deliver it.

My team was responsible for compiling and analyzing YouTube shopping data: things like product sales volume, buyer age demographics, most popular items, videos with the highest sales, and so on. After organizing the data, we displayed it on a website called YouTube Merchant Center. Most people don’t know about this site, but you can think of it as the backend dashboards for merchants, similar to how YouTubers have their creator backend to check their channel’s performance. “YouTube Merchant Center” is like the backend dashboard for merchants such as Walmart, allowing them to see how their products are performing on YouTube.

So here’s how our team worked: at the beginning of each quarter, we gathered merchant feedback and feature requests, and then decided which ones must be completed that quarter. For example, if merchants wanted to know the click-through count of their items, we had to figure out how to collect that data and display it on Merchant Center. You might think: “Isn’t a click count just a number? How hard can it be to put a number on a website?” I thought that too until I started doing the work and realized how difficult it really was. One person could easily spend weeks on a single feature, sometimes even months.

We can break down this “click count” feature into the following steps:

Product Requirement Document (PRD)

Sometimes this step alone takes weeks. First, we need to figure out exactly what the client wants. Do they want the click count for each product? Or the click count for each product in each video? Do they want the top 10 products with the most clicks? Or the top 10 videos with the highest click-through rate? Or the influencers with the highest click-through rate?

And what exactly is a “click”? If a product is sold in the U.S., should clicks from viewers in Taiwan count? Should invalid clicks be counted separately? If a viewer watches a video once but clicks the product link three times, do we count that as one click or three? Do clicks from the video description count, or only clicks from links directly in the video? Should Shorts and livestreams be included? Going back and forth with the client to clarify these details can take several weeks.

Design Document

Once the requirements are finalized, we can start writing the design document. Not all tasks need a design doc, but complex features definitely require one so that other engineers can review, discuss, and approve the design.

For click counts, we must determine:

• Where is the data coming from?
• How will we store it in the database?
• How will the front-end fetch and display it?

And so on.

Design documents usually involve trade-offs. For example, if merchants only need the top 10 products by click count, we can simplify things by precomputing just those ten products and storing only those numbers in the database. This makes everyone’s life easier but offers less flexibility.

Alternatively, we can store the click counts for every product on every video, then compute whatever rankings the front-end needs. This design is far more flexible: if clients later want the top 100 products or the top 10 videos, the data will already be there. But it takes more time to design, requires more storage, and causes heavier query loads.

Coding

After endless reviews and meetings, once the design is finally approved, we can finally start coding. Coding itself can be time-consuming, but testing and deployment can also take a lot of time.

Testing ensures there are no bugs. Depending on complexity, some system tests can take hours to run. After testing is done, the feature can be deployed. But deployment schedules vary: code written today and fully tested may take days to go live.

And deployment isn’t just one step. There are multiple deployments: data processing systems, backend services, front-end systems, etc. Front-end engineers often need to wait for backend deployment before testing; backend engineers need to wait for new data pipelines before verifying their work. These dependencies mean one person waits for another, and one deployment waits for another, so the whole process can easily take more than a week.

The later a bug is discovered, the more expensive it becomes. In a worst-case scenario, imagine discovering during website testing that the client actually wanted “click-through rate” instead of “click count.” That means going all the way back to redesigning the system. In semiconductor terms, it’s like discovering a circuit design flaw when you’re about to begin mass production: utterly disastrous.

Approvals

Once the code is complete and you're about to celebrate and shut down your computer, your manager reminds you to schedule all the necessary approval meetings; the approval process is just beginning.

What kinds of approvals?

1. Accessibility: Is the website friendly to color-blind users? Can screen readers read the numbers for visually impaired users?

2. Localization and Internationalization: If a French merchant logs in from the U.S., and the product is sold in Germany, should the product name be shown in German, French, or English? These details should have been covered in the design doc.

3. Privacy Review: If a product only has 1 click, is it too easy for merchants to deduce which user clicked it?

4. Legal Review: If we show an incorrect click count, could we be sued? If we compile user click data, could users sue us?

---

Two months later, after the coding is done and all approvals are completed, the Business Unit sends an announcement: the feature must be canceled immediately.

Based on their research, publishing click-count data would cause merchants to remove unpopular products, reducing the diversity of items available on YouTube. This would harm YouTube’s long-term growth.

You stare at the email and sigh. All that work for nothing. And that’s when you truly understand: software updates really are incredibly difficult.