check

Thank You

Your submission is being reviewed.

We'll get back to you asap.

Check out our Blog

Recently I was talking with a great software architect I’ve worked with for years. During our conversation, we covered organizational structures and the ways that you can “read the tree rings” of an organization by looking back through the software they have built. Before long I realized that we were talking about the last of the three laws of software development—Conway’s Law. If you are not familiar with these laws, then consider this your primer to the foundational principles of the software world.

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. Peter Saddington puts it in straightforward terms: “People don’t know what they want until they see what they don’t want.” This is often simplified further—users don’t know what they want until they see it. 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.

Second, we have Ziv’s Law, which can be found in Jeff Sutherland’s book Exploring Scrum: The Fundamentals. It is probably the most self-evident of the three, distilling down to the idea that “software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood.” 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 the hubris of 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.

The last of the three laws, called “Conway’s Law” after Melvin Conway states: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.” 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.

Whether you are a business owner, manager, or developer, you can understand these three laws as the presuppositions that most 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.