How privacy laws differ in California and Federal

Hyrum’s Law in Today’s Software Development and Architecture One principle that constantly resonates with me in the world of software development is Hyrum’s Law, which states: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.” In simpler terms, anything your software does—intentionally or not—will eventually become a dependency for someone. This reality challenges how we design, build, and maintain our systems in an interconnected world. Why Hyrum’s Law Matters Today In a rapidly evolving tech landscape, where APIs and microservices drive integrations, Hyrum’s Law warns us about the hidden dependencies that can undermine innovation and agility. For example: • Backward Compatibility Issues: Imagine updating your API to optimize performance, only to realize a major customer’s integration relies on an undocumented edge case that is now broken. Example: A SaaS platform updated its billing API, causing a customer’s payment gateway integration to fail because it depended on a specific error message format. • Unintended Consequences in Observability: Engineers tweaking logging levels to reduce noise might inadvertently break downstream services that rely on log patterns for alerting. Example: A team at a fintech company optimized database query logs, unknowingly affecting a fraud detection system relying on those logs for monitoring patterns. • Feature “Misuse” Becomes Standard: Features built for one purpose are often used in ways developers never anticipated. Example: A feature flag system designed for internal testing becomes critical to a customer’s rollout strategy, making its removal impossible. What Can We Do About It? 1. Document and Communicate Explicitly: Ensure your contracts and interfaces are well-documented, but also acknowledge that documentation won’t cover every edge case. Communicate upcoming changes early and often. 2. Design with Observability: Implement robust monitoring and telemetry to understand how your systems are actually being used—not just how you intended them to be. 3. Use Deprecation Strategies: Plan deprecations with long timelines, versioning, and clear migration paths to avoid breaking critical dependencies. 4. Embrace Chaos Testing: Simulate potential failures to uncover unexpected dependencies and edge cases before your customers do. 5. Collaborate Cross-Functionally: Work closely with your business and customer success teams to anticipate how products are being used beyond the original scope. Final Thought Hyrum’s Law is not a problem to be solved—it’s a reality to be managed. By acknowledging the inevitability of unexpected dependencies, we can build systems that are resilient, adaptable, and customer-centric. How have you encountered Hyrum’s Law in your work? I’d love to hear your stories! #SoftwareDevelopment #Architecture #APIs #EngineeringLeadership #Resilience

#Hyrum's Law Hyrum's Law that describes a situation that arises when developers depend on the observable behavior of a system, rather than just the official documentation. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." The key idea of it: 1. Software interfaces, like APIs, have a documented contract that outlines how they should function. 2. But developers, over time, will also rely on any consistent, non-documented behaviors they observe from the system. This can cause problems because: 1. If the undocumented behavior changes, it can break applications that depend on it. 2. This is sometimes referred to as "bug-for-bug compatibility" because any changes to the system must now consider both the official documentation and how developers are actually using it. Here are some ways to address this challenge: 1. Clear documentation: Having thorough documentation helps developers understand the expected behavior of the API. 2. Backward compatibility: When making changes to an API, try to maintain compatibility with existing code as much as possible. This might involve keeping unintended behaviors for a while or providing a migration path for developers. 3. Gradual Changes: When modifying or introducing new features, aim for gradual changes whenever possible. This allows users to adapt gradually, reducing the risk of sudden disruptions. By understanding Hyrum's Law, software developers can build more robust systems and avoid unintended consequences when making changes.

Great journalistic piece and very fair article in The Register today by Richard Speed which concisely covers all the major issues in the software world which have been top of mind for me. (Still on a social media break so won't be responding to comments.) https://lnkd.in/ei6ynjQf Data tables of the opinion research mentioned in the piece for anyone curious (conducted by Survation on behalf of me late last year): https://lnkd.in/edYUiXha

John Gall in THE SYSTEMS BIBLE says: “A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.” Gall's Law as a law of functional software: If you want to write a program that works, it’s better to start small and simple. The idea of creating a massive, feature-packed software right from the start is just asking for trouble. Gall's Law states that every complex system that actually works started out as a simple, functional system. You can't simply conjure up a complex system and expect it to work flawlessly. That's like expecting a newborn baby speaking fluent JavaScript – it's just not going to happen. Consider the World Wide Web (WWW), which began humbly and didn't materialize overnight. It started with simple systems that worked and then gradually evolved into the platform we know and love today. On the other hand, we have protocols like CORBA, which most of us have never even heard of because it was a failure. This law applies to more than just software; it also applies to economic and political ideologies, for example. We've all been there, making resolutions to turn our lives around. We've got the perfect plan, the perfect routine, and the perfect mindset. And then, faster than we can say "procrastination," it all falls apart. So start small, fix those tiny habits, and gradually work your way up. It actually works. Be agile, be open to change, and don't try to do everything at once.

Are you prioritizing ethics and privacy in your code? 🗝️ Be a developer who promotes integrity and user trust. Join us on October 30 for an exclusive event where we'll reveal Proxify's strategies for embedding ethics and privacy into every stage of software development. Reserve your spot today and lead responsible software development. The link is in the comment section below.

🎓 Learning Something New Every Day The other day, I discovered the name for something I had already noticed but didn’t know had a formal term: Hyrum’s Law. This law highlights an interesting reality in software development: 👉 "With a sufficient number of users of an API, it doesn’t matter what you promise in the contract: all observable behaviors of your system will be depended upon by someone." In simpler terms, it means that users rely not only on your API’s official promises (the API contract) but also on every observable behavior of your system—even the undocumented or unintentional ones. While some impacts are obvious—such as response times, the order of results, payload formats, or default values—others are more subtle: 🤔 A vague error message, once fixed to provide more detail, might break workflows that depended on the old message. ✨ Changing spacing or formatting in an HTML response can disrupt parsers. 🍪 Renaming a cookie, altering its format, or changing its properties can break client integrations. 📄 Adjusting the number of spaces in an exported file can unexpectedly affect downstream systems. It’s fascinating how human ingenuity works. Fixing a bug might end up harming those who benefited from it, and tweaking an “improvement” might create unintended challenges for others. As developers, we innovate and adapt to every little input or behavior—even the quirks—building solutions in ways no one might anticipate. 💡 Have you encountered any examples of Hyrum’s Law in your projects?

💡Only a few organizational architectures work well for flow, so orgs need to understand their value flows before embarking on reshaping the org. [Sales pitch: my teams at Conflux and Team Topologies can help with all this - get in touch!]

For anyone developing software products and services, this is a cracking blog post from Bob Salmon. Thanks for sharing, Bob!

⚖️ Worried about hallucinations in your GenAI RAG application? Your legal team probably is too. When your LLM is giving unpredictable or inaccurate answers, you need Performance-Driven Development (PDD) to create transparency and ensure reliability. Here’s how PDD can help calm those lawyer nerves: 1️⃣ Break Down Scenarios of Concern: Your legal team has a list of critical areas where the LLM might give inaccurate answers. For example, they might worry about how well the LLM handles sensitive legal topics like contract law or employee disputes. With PDD, you turn those concerns into a set of representative tasks. You list the questions that the LLM should handle correctly, ensuring you capture all the tricky scenarios. 2️⃣ Build a Performance Evaluation Framework: Now that you have a clear set of tasks, create a framework that measures how well the LLM performs. Is it retrieving the right documents? Is it answering legal questions accurately? PDD ensures you have the metrics to see exactly where your system is succeeding—or failing. 3️⃣ Review with Stakeholders: Share these performance reports with your legal team. Show them real data, not just a demo. With transparency from PDD, they can provide feedback on where the system needs to improve, helping you refine your solution with confidence. Don’t let hallucinations derail your LLM project. With PDD, you turn vague concerns into measurable tasks and data-backed transparency. 🧠🔍 🔗 Get started with PDD today: https://lnkd.in/dcNKWQcS #pdd

Achieving privacy compliance with your CI/CD: A guide for compliance teams