4 ms·

It's a bit alarming that bug numbers at Google are now in the hundreds of thousands.

by kens 5y ago

mikewarot 5y ago
It's my understanding that over time, bugs outnumber lines of code. Google has millions, maybe billions? of lines of code.
bombcar 5y ago
Imagine the sound in the datacenter with JIRA spinning to life on 219 million bugs.
- Waterluvian 5y ago
  Some say they never commissioned it properly and it’s still using the demo XML file as the database.
efsavage 5y ago
Bug is used very broadly, any issue/task is a bug, some of which are of type "Bug".
crayboff 5y ago
I would be alarmed if a company the size of Google with as many complicated projects and as many different developers didn't have a bunch of low level issues like this hanging around!
deleted 5y ago
[deleted]
bhawks 5y ago
The system's external name is IssueTracker[1]. Internally it's name is buganizer. Buganizer has been around forever (or it already had a ton of bugs logged when I started in 08). It gets (ab)used to store tons of semi structured data with a pretty good siloing and acl capability (including allowing Google 3rd party partners to work on issues). This data includes bugs but also tasks, workflows, approval processes etc. Buganizer is very api-first so many different tool frontends use it as their backend. Generally every huge leap in bug numbers was associated with buganizer assimilating another tracker's bug database (from acquisitions and similar). For what it's worth no issue tracking system I am aware of has avoided buganizers huge gravity well. I expect this trend to continue. 1: https://issuetracker.google.com https://issuetracker.google.com
- TheFreim 5y ago
  > For what it's worth no issue tracking system I am aware of has avoided buganizers huge gravity well Even some small, well managed, projects will develop hundreds upon hundreds of issues in their trackers. Can't imagine how you'd deal with that at such a massive scale.
  - triggercut 5y ago
    AI assisted prompts to users to provide more structured context[1], de-duplicate, cluster, prioritise. All things people _should_ be doing but can't be bothered to or aren't incentivised to. Who here hasn't been in a standup where a task was created against a CL that only had a title "FIX" (with the intention of filling it out later) Complex Project Management in other sectors (construction) is starting to see life in this regard. Unfortunately much of the digital transformation of PM to date has focused on capture and reporting. Capture is capture but the problem with reporting is that nobody read the reports before and aren't going to read them now they are in dashboard with endless possibilities to slice and dice. Automating insight is next but insight is difficult to draw when you have tens to hundreds of people building an often unreliable, usually bespoke, and piecemeal semantic model over time; quality and context is scattershot and the datasets not large enough on their own and not comparable to others. [1] e.g. Clippy but AI that gets better as teams provide feedback: Does this issue relate to x or y? Is this issue A more important than this issue B? Was this issue A fixed by this PR B?
jeffbee 5y ago
Piper revisions are at 429321455*, so that's about 1 issue per CL. Sounds about right in fact. *Or were a little while ago when Abseil was last updated.
renewiltord 5y ago
That's true. All of my personal projects have bug numbers only in the single digits. Just more evidence that I am better than all of Google.

It's a bit alarming that bug numbers at Google are now in the hundreds of thousands.

by kens 5y ago

It's a bit alarming that bug numbers at Google are now in the hundreds of thousands.

It's my understanding that over time, bugs outnumber lines of code. Google has millions, maybe billions? of lines of code.

bombcar 5y ago

Imagine the sound in the datacenter with JIRA spinning to life on 219 million bugs.

Waterluvian 5y ago
Some say they never commissioned it properly and it’s still using the demo XML file as the database.

efsavage 5y ago

Bug is used very broadly, any issue/task is a bug, some of which are of type "Bug".

crayboff 5y ago

I would be alarmed if a company the size of Google with as many complicated projects and as many different developers didn't have a bunch of low level issues like this hanging around!

deleted 5y ago

[deleted]

bhawks 5y ago

The system's external name is IssueTracker[1]. Internally it's name is buganizer. Buganizer has been around forever (or it already had a ton of bugs logged when I started in 08). It gets (ab)used to store tons of semi structured data with a pretty good siloing and acl capability (including allowing Google 3rd party partners to work on issues). This data includes bugs but also tasks, workflows, approval processes etc. Buganizer is very api-first so many different tool frontends use it as their backend. Generally every huge leap in bug numbers was associated with buganizer assimilating another tracker's bug database (from acquisitions and similar). For what it's worth no issue tracking system I am aware of has avoided buganizers huge gravity well. I expect this trend to continue. 1: https://issuetracker.google.com https://issuetracker.google.com

TheFreim 5y ago
> For what it's worth no issue tracking system I am aware of has avoided buganizers huge gravity well Even some small, well managed, projects will develop hundreds upon hundreds of issues in their trackers. Can't imagine how you'd deal with that at such a massive scale.
- triggercut 5y ago
  AI assisted prompts to users to provide more structured context[1], de-duplicate, cluster, prioritise. All things people _should_ be doing but can't be bothered to or aren't incentivised to. Who here hasn't been in a standup where a task was created against a CL that only had a title "FIX" (with the intention of filling it out later) Complex Project Management in other sectors (construction) is starting to see life in this regard. Unfortunately much of the digital transformation of PM to date has focused on capture and reporting. Capture is capture but the problem with reporting is that nobody read the reports before and aren't going to read them now they are in dashboard with endless possibilities to slice and dice. Automating insight is next but insight is difficult to draw when you have tens to hundreds of people building an often unreliable, usually bespoke, and piecemeal semantic model over time; quality and context is scattershot and the datasets not large enough on their own and not comparable to others. [1] e.g. Clippy but AI that gets better as teams provide feedback: Does this issue relate to x or y? Is this issue A more important than this issue B? Was this issue A fixed by this PR B?

jeffbee 5y ago

Piper revisions are at 429321455*, so that's about 1 issue per CL. Sounds about right in fact. *Or were a little while ago when Abseil was last updated.

renewiltord 5y ago

That's true. All of my personal projects have bug numbers only in the single digits. Just more evidence that I am better than all of Google.