A few weeks ago I was talking with a mentor of mine about product roadmaps. We went back and forth on the value and importance of a vision, strategy and if capturing that in the form of a roadmap made sense. After a few minutes of discussion, he pointed out a common complaint with them, “About five minutes after you write a roadmap it’s outdated.” And he was right.
Roadmaps, while valuable, reflect a moment in time rather than the way things will necessarily play out. This is yet another example of Ziv’s law and the hubris it attempts to protect us from. If you haven’t heard of Ziv’s law, or the two others that are known as the three laws of software, then consider this your first introduction.
Humphrey’s Law: “People don’t know what they want until they see what they don’t want.”
Let’s start with Humphrey’s Law, which is arguably the most important of the three and which has far-reaching and organizational-wide implications. This is one of the primary reasons large software companies like Google, Microsoft, and Apple, prefer releasing incremental updates. It gives time for users to see what they do and don’t want. That feedback then gives the development teams the time and information to quickly update the software.
These organizations have learned that trying to build the “perfect” software solution for a user is not a one-and-done deal. Rather, it requires numerous iterations and consistent validation from real users. This is why Humphrey’s law is often considered a cornerstone of agile development.
Ziv’s Law: “Software development is unpredictable and the documented artifacts such as specifications and requirements will never be fully understood.”
Second, we have Ziv’s Law, which can be found in Dan Rawsthorne’s book Exploring Scrum: The Fundamentals. It is probably the most self-evident of the three. At its core, software development is new product creation. And whenever creating a new product, we can never be sure of all the needs, contexts, specifications, and requirements. All of these things are subject to change during the creation process. Ziv’s law acknowledges the uncertainty present in any new endeavor (no matter how similar to something we have created before).
The natural conclusion of Ziv’s law is twofold, first, we should avoid thinking, at any point, that we fully understand the requirements of a given solution, both technical and functional. And second, our documentation and planning must accommodate the evolutionary process present in software developments unpredictable nature.
Conway’s Law: “Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”
If your organization suffers from poor teamwork and coordination, your software will reflect that.
Software always reflects the people designing and building it. This law is about realizing that software creation does not happen in a vacuum; it’s not subject to a single manager’s or executive’s will, but rather is a product of the complex communicational structures within the organization. If your organization suffers from poor teamwork and coordination, your software will reflect that. Or if your company has strong competing views within departments and no sense of who is responsible for decision making, then you can expect a piece of software lacking in discipline, continuity, and direction.
These three laws are the presuppositions that most agile software development methodologies are built on. While these laws may not be etched in stone, they are deeply branded into the thousands of organizations that have both failed and succeeded at the difficult task of creating software.
Based in Middle Tennessee, Isaac Wuest writes about the lessons of being a consultant in Product Management and Business Analysis.