## The Peril of Implicit Assumptions in Software Every software engineer eventually writes a bug rooted not in syntax or algorithmic complexity, but in a fundamentally false assumption about how the real world operates. Inspired by **[Kevin Deldycke's iconic `awesome-falsehood` open-source repository](https://github.com/kdeldycke/awesome-falsehood)**, this article deconstructs the most notorious traps in software engineering: timezones, calendar math, human identity, network guarantees, and database transactions. --- ## 1. Falsehoods Programmers Believe About Time & Dates Time is not a monotonically increasing continuous number of seconds. When building financial ledgers, job schedulers, or analytics pipelines, developers frequently assume: ### The Fallacy List: 1. **"A day always has 24 hours (86,400 seconds)."** *Reality:* Daylight Saving Time (DST) transitions cause days to have 23 or 25 hours. Leap seconds introduce 86,401 seconds. 2. **"UTC never changes its offset."** *Reality:* Countries change their timezone boundaries, adopt or cancel DST with short notice (e.g., Egypt, Jordan, Samoa). 3. **"Two timestamps recorded in sequential code will always be ordered chronologically."** *Reality:* NTP clock sync skew and VM hypervisor pauses can step system clocks backward. Always use `time.monotonic()` in Python or `performance.now()` in JavaScript for durations, never wall-clock time (`time.time()`). ```python # ❌ INCORRECT: Measuring elapsed duration with wall clock import time start_wall = time.time() # ... network or database query ... # If NTP synchronizes backwards here, elapsed can be NEGATIVE! elapsed = time.time() - start_wall # ✅ PRODUCTION PATTERN: Monotonic Clock start_mono = time.monotonic() # ... execute operation ... elapsed_seconds = time.monotonic() - start_mono ``` --- ## 2. Falsehoods Programmers Believe About Human Names Form validation fields like `First Name (required)` and `Last Name (required)` routinely fail across international user bases. ### Why Rigid Name Schemas Break: - **Mononyms:** Many people across Indonesia, Myanmar, and Iceland have only a single legal name (e.g., *Suharto*). - **Hyphens, Apostrophes, and Numbers:** Names like *O'Connor*, *Al-Mansoor*, or numeric names in indigenous cultures. - **Length Constraints:** Valid names can be 1 character long (e.g., *U*) or exceed 100 characters. - **Capitalization Assumptions:** Names do not always start with an uppercase letter (*van Gogh*, *de Silva*). ```python # ❌ INCORRECT: Assuming First + Last split def parse_full_name(full_name: str): parts = full_name.strip().split(" ") return {"first": parts[0], "last": parts[1]} # Crashes on mononyms or multi-part surnames! # ✅ RESILIENT PATTERN: Single display name field with optional preferred name class UserProfile(models.Model): full_name = models.CharField(max_length=255, help_text="Full legal or preferred display name") preferred_call_name = models.CharField(max_length=100, blank=True) ``` --- ## 3. The 8 Fallacies of Distributed Computing When moving from a single monolith server to microservices or cloud APIs, engineers often make the classic Peter Deutsch fallacies: 1. **The network is reliable.** (Packets drop, Wi-Fi toggles, SSL handshakes timeout). 2. **Latency is zero.** (Cross-region ping is 80–200ms). 3. **Bandwidth is infinite.** (Transferring 50MB JSON payloads saturates queues). 4. **The network is secure.** (Always encrypt in transit with mTLS). 5. **Topology doesn't change.** (Kubernetes pods auto-scale and rotate IPs). 6. **There is one administrator.** (Third-party APIs change without notification). 7. **Transport cost is zero.** (Cloud egress fees are significant). 8. **The network is homogeneous.** (Heterogeneous mobile networks and firewalls). --- ## 4. Idempotency: The Universal Antidote to Network Retries Because the network will fail, requests *must* be retried. But retrying a non-idempotent operation (like charging a credit card or creating a student record) creates catastrophic duplicates. ### Architectural Blueprint: Idempotency Keys in Django & Python ```python import hashlib from django.core.cache import cache from django.http import JsonResponse def process_order_with_idempotency(request): idempotency_key = request.headers.get("X-Idempotency-Key") if not idempotency_key: return JsonResponse({"error": "Missing X-Idempotency-Key header"}, status=400) cache_lock = f"idemp_lock:{idempotency_key}" cache_result = f"idemp_result:{idempotency_key}" # 1. Check if response is already cached from previous successful execution cached_payload = cache.get(cache_result) if cached_payload: return JsonResponse(cached_payload, status=200) # 2. Acquire atomic lock (prevents concurrent race conditions) if not cache.add(cache_lock, "1", timeout=30): return JsonResponse({"error": "Concurrent request in flight. Retry shortly."}, status=409) try: # Perform actual business logic here order_result = execute_business_transaction(request.POST) # Cache outcome for 24 hours cache.set(cache_result, order_result, timeout=86400) return JsonResponse(order_result, status=201) finally: cache.delete(cache_lock) ``` --- ## 5. Summary & Key Takeaways 1. **Never use wall-clock time for measuring latency or intervals.** Use monotonic clocks. 2. **Never split names by space.** Store a unified full name field. 3. **Always assume network calls will fail or timeout.** Implement exponential backoff jitter and idempotent handlers. 4. **Read Kevin Deldycke's `awesome-falsehood` on GitHub** to discover falsehoods about postal codes, telephone numbers, emails, and CSV parsing before writing your next model schema.