Monday, July 21, 2014

The Three Laws of Software Development - Ziv's Law

(previously published on LinkedIn)
During a recent class, Peter Saddington referenced three laws which collectively are knows as the Three Laws of Software Development:
  1. Humphrey's Law
  2. Ziv's Law
  3. Conway's Law
I wrote about Humphrey's Law in my previous post.

Looking up "Ziv's Law" you'll find it in Jeff Sutherland's book "Exploring Scrum: The Fundamentals." Ziv's Law states that software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood. First we need to all agree that new product design is the fundamental nature of software development - and that basically whenever we're creating something new, no matter how close it is to something we've done before, it's impossible to be confident of all the constraints and needs of this new development. Sure we can do some affinity comparisons to something we've done previously, but there's always some variability (if there wasn't then why didn't we just use what was built the first time?), and it's virtually impossible to predict the outcome with much accuracy due to this variability. And further, the more the new development diverges from the previous, the more unlikely the accurate prediction of the outcome.

This law, much like Humphrey's Law, is about uncertainty. It's all about the precision of functional and non-functional requirements in regards to software development projects - no matter how well they are understood and written during the time of scoping and initial refinement, things tend to change while the actual development is going on (whether the business need changes or there are changes inherent to the development process itself that impact the complexity). This law is important because it's fundamental to understanding how the agile process, and scrum in particular, addresses this particular issue.

With scrum, because the intervals are fixed and the stages of development divided into bite-sized chunks that can fit into the interval, there's more room to make adjustments in the subsequent intervals (sprints) to allow for what is discovered. This also brings into play the experiences of those working on the user story (i.e. your technical team) so you're already getting additional input into the outcome. All this leads to a much more satisfying final product, both for those involved in the process and for those who are supporting or needing the results of those efforts - and after all, that's what we are trying to do, delight the customer (general term for whom we're doing the effort).

So why is this law important? It has to do with failure and what we do as a result of failure. If we accept that what we are building in any one sprint isn't perfect, then we'll understand that the feedback we receive from the customer for what's been done can be incorporated into the next sprint, allowing us to make adjustments to a final, satisfying outcome. Small failures are OK and should be expected - it's the ultimate result adjusting to those small failures that will make us successful.

-- John


  1. I found your this post while searching for some related information on blog search...Its a good post..keep posting and update the information los angeles dog bite lawyer

  2. This comment has been removed by the author.

  3. This comment has been removed by the author.

  4. This comment has been removed by the author.