{
  "id": 18925950,
  "title": "The box that fell behind a seat: what delivery logistics taught me about data between systems",
  "url": "https://urgent.news/2026/11/08/the-box-that-fell-behind-a-seat-what-delivery-logistics-taught-me",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-08T11:47:57.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/nutts5796/the-box-that-fell-behind-a-seat-what-delivery-logistics-taught-me-about-data-between-systems-291f"
  },
  "original_language": "en",
  "account": "The delivery process involved multiple parties, including drivers, mobile apps, storekeepers, and accountants, each maintaining their own version of the truth. Four such versions of the same order could coexist, leading to inconsistencies. The discrepancies most often arose around quantity and address. When these mismatches occurred, investigators would compare the four records, a process that could take two to four hours, involving calls between departments each with a partial view of the situation. The resolution usually fell into one of three categories: the item was found and re-delivered, the item was confirmed lost with compensation paid, or a mistake in the records was identified. One memorable case involved a customer claiming that part of their order never arrived. The waybill showed the item was loaded, the mobile app indicated delivery, and the customer was convinced otherwise. The missing item turned out to be hidden behind a seat in the delivery van, picked up by the driver en route. This incident underscored that every system could be technically correct on its own, yet disagreements could arise. As a driver, the author observed that a lot of data problems originate from individuals attempting to manually prove something that has already been completed. The author's transition into software testing revealed a recurring pattern: the same order, payment, or report existed in various interfaces, APIs, exported files, and databases, all of which passed their respective tests. The real bugs emerged at the interface between these systems. Thus, testers should ask where else the data resides, identify the reference source, confirm the definitive source, determine the responsible party for discrepancies, and implement a systematic approach to comparing data across multiple platforms. By adopting this habit, the author believes software for logistics can be significantly improved, and unnecessary driver penalties can be avoided.",
  "summary": "Before I became a QA engineer, I ran transport logistics at a delivery warehouse near Moscow. Every day 50 to 60 drivers left our gates, and together they made about 2,500 to 3,000 deliveries. Later, for a few months, I drove a delivery van myself, doing 70 to 100 drops a day. I now test software for a living. The longer I do it, the more I think the most useful lessons about data quality came…",
  "key_points": [
    "Multiple parties maintain separate versions of order details",
    "Discrepancies often involve quantity and address information",
    "Missing item found behind a seat in delivery van"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}