Skip to main content

What You Measure

2 months ago

Rachel joined a new team which was proudly "metrics driven". When she first met with her boss, Zane, he explained his thinking.

"We need to be data-driven to make good decisions, right? We're a manufacturing company. We make widgets. At the end of the day, we need to make the most widgets for the lowest cost of goods sold. So we track that, and that feeds into every decision."

The team oversaw an automated production line, which meant the software was a mix of robotics, embedded firmware, high-level web based monitoring tools, and thickets of dreaded PLC code. And because you can't build an entire factory for test purposes, they only way they could test real-world scales with real-world data was to roll changes out to production. They could simulate, they could run tests on subsets of the system, but a change in the production line software couldn't truly be validated until it rolled out into the real world.

Rachel's first task on the new team involved making some changes to their metrics dashboard. It was viewed as a good way to get her feet wet with the new team. As it turned out, the metrics dashboard was a Google Sheet, with a complex series of formulas that involved multi-level INDEX functions- essentially querying the spreadsheets like they were a database. Why not use an actual database? Oh, they did — six actually — but the company obeyed Remy's Law of Requirements Gathering: "no matter what the requirements the users ask for, what they really wanted was Excel". The database data was pulled into the spreadsheet for reporting.

Now, a complicated sheet pulling in data from not one, but six different databases, they must have a pretty complex model to explain how changes to their software would impact productivity. And since they needed to model the software to make predictions about how it'd behave in production, that model must be extremely useful.

Of course it wasn't. The only metrics they tracked were output metrics, variations on "widgets produced per unit time". There were some performance metrics, so you could maybe potentially identify "oh, our overall throughput dropped because unit 5 became a bottleneck and started taking 1.5 extra seconds per widget", but nothing that actually helped you understand how the complex system made decisions. Or even why unit 5 was taking longer.

For example, there was an automated quality control scanner. It examined widgets as they came off the line, and rejected defective ones based on a computer vision algorithm. Did that subsystem record why it rejected a widget? No, it did not. The CV model was able to tag widgets with a defect category based on what it saw, but that information didn't get recorded anywhere. In fact, it didn't even record how many widgets got rejected. The only way to know was to have an operator on the assembly line count widgets in the bin manually. Since that ate up a bunch of an operator's time, it never happened unless the developers begged for it. And since the operator still couldn't answer the question "why was this widget rejected", it wasn't all that useful anyway.

Every change to the software was scored against the overall output metrics. This meant that when Rachel was ready to push out her first software change, something that would record how many widgets were rejected and why, whether or not it could be deployed was dependent on seeing the change improve, or at least not regress, the widgets-over-time scores. But the widgets-over-time were a noisy metric; it varied based on which operators were working any given shift, or based on supply chain constraints. Or sometimes, based on when one of the machines was last calibrated- theoretically something that happened on a set schedule, but really was up to the operators. This meant the first three times Rachel rolled her code out for a test run, the metrics regressed. Nothing she changed should have impacted the metrics, but the metrics regressed due to environmental issues.

This meant making a simple change could take weeks, because you could only do final validation on the real system, which means you had to mark off a block of time for a test run, you could only run a handful of tests a day, and if metrics regressed you had to account for that before you could release the software for actual production use.

Over the first few months, Rachel added instrumentation to the code. Anything along the way to generating an output widget, she recorded. The hope was that once they had enough data, they could build a useful model of the system. Unfortunately, Zane had other ideas.

"So, you haven't improved our metrics," Zane said. "Which, I remind you, we're a metrics driven organization. Every change needs to improve our metrics."

"Sure, but I'm gathering more data so we have a better idea of what makes our metrics tick. We don't know why our system does some of the things it does, because we don't record any logging about the decisions it makes."

"Right, but we already gather the key metrics."

"But you don't gather the data that tells you why those metrics are what they are!"

"Sure," Zane said. "But those aren't our key metrics."

That, unfortunately for Rachel, was where things landed. Understanding their complex system was a low priority. Pushing top-level metrics without understanding what fed into them, that was the priority. That didn't mean Rachel was powerless: any time she made a change that she thought might help the top level metrics, she also made sure to add instrumentation that explained how that change behaved. It was the compromise that kept Zane happy: she released features that impacted the top-level metrics, but she also made the system more observable.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!
Remy Porter

LZ Experiment Sees Surprising Result In Search For Dark Matter

2 months ago
New submitter greytree shares a report from Brown University: LUX-ZEPLIN, an experiment co-led by Brown University faculty and students, observed a particle interaction that could be interpreted as a signal from WIMPs, a dark matter candidate -- but researchers need more data to confirm. [...] The result does not yet meet the statistical threshold required to claim a discovery, but it is the most compelling hint of dark matter reported by the experiment to date. "We're very intrigued to see this event in the data, in the region where we expect dark matter to show up, and the competing backgrounds are very low," said Rick Gaitskell, a professor of physics at Brown University and the spokesperson for LZ. "With only one event, we don't want to get ahead of ourselves. We are not claiming to have seen dark matter. But we have seen something interesting that we want to share with the scientific community for their input." [...] If the anomalous event was caused by dark matter, the WIMP that generated it would likely have a mass of at least 200 GeV/c2 (gigaelectronvolts), or more than 200 times the mass of a proton. The LZ results have not reached "5-sigma" significance, the statistical threshold in physics that an event must reach to be considered a discovery. The new analysis is 2.6 sigma, meaning there is approximately a 0.5% chance that the event could be explained by known backgrounds. With additional data, researchers can test whether the finding continues to grow in significance or fades away. LZ has already accumulated the world's largest dark matter dataset and will continue to accrue WIMP search data at SURF, substantially improving their search statistics. JiJi Fan, an associate professor of physics at Brown not involved in the LZ experimental research but whose theoretical work is cited in the new LZ paper, said the new findings were "very intriguing." While the event recorded by LZ could not have been the simplest type of WIMP interaction, there are other types of possible interactions that could explain it, she said. Had a WIMP interacted in the simplest way at the high energy associated with this recent event, the detector would have recorded many recoil events at lower energies following the initial event. LZ recorded a single event, however, which requires an expanded theoretical explanation. "There are well-motivated theoretical extensions, including inelastic scattering and momentum-dependent elastic scattering, that could potentially account for this single event," Fan said. "This also sets up a target for on-going dark matter hunting, not only at direct detection experiments such as LZ but also at other complementary experimental frontiers." The results were presented in a scientific talk at the 2026 TeV Particle Astrophysics conference in Japan on Tuesday, Sept. 1. A paper detailing the finding can be found here (PDF).

Read more of this story at Slashdot.

BeauHD