Water is fluid, soft, and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft, and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong.
- Lao Tzu
In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. - Here
Our most finite resource is time. That is a statement that cannot be refuted in our physical universe. As in any business, in software development time is money. Money is the finite resource in any project (this statement could be refuted, but that would be unpopular with most stakeholders). Templates exist to save time, and a pattern in software development is a template. That is why we follow patterns, and that is how business continues.
This is a metaphor I apply widely to any human activity, albeit mostly in the context of software development. Patterns are more than our templates - they exist before we conceive of them. We detect and implement them, but we cannot truly say we invent them. They evolve and actually become stronger due to adoption, and that adoption does not occur through our enforcement. A person may put a name to a pattern, but one person alone cannot establish a pattern. We find a signal in the noise and we follow it, collectively.
User stories have been widely adopted as a means of organizing work. A user story must represent something of value to a user. A common example is: by performing this action, the user saves time doing X. This is possibly the oldest user story in the world.
I wake up in the morning, I grab my phone. I open an app. Let's say I just installed it. I look at a screen and have to do something for the app to add value. If I spend more than 30 seconds looking at the screen and have not done something, I will likely uninstall the app and move on. I may even feel the desire to throw my phone out the window.
The value pattern means consistently asking the question: how does this thing add value? In those 30 seconds we can detect whether the value pattern has been followed or not.
One could argue: "well, that is why we test products." But that clearly does not address the issue, or I would still be holding the phone in my hand and not ordering a new one.
The value pattern consists of asking this question at every stage of development, from user story creation up to and including the Sprint demonstration. Why? Just like the adopting of patterns, one person alone cannot be responsible for answering the value question. If the value cannot be clearly demonstrated and accepted by a group of people, there is a greater risk that the larger group will be throwing away phones.
We naturally tend to focus on acceptance criteria, and that criteria becomes a proxy for value. This is a conceptual hand off that adds risk. Depending upon how mature a team is in its adoption of Agile and Scrum, the acceptance criteria may even become confused with testing of software. This adds an incredible amount of risk: a team produces impeccable code based on the best known patterns, we validate that it is impeccable, and we move on.
I just threw away a phone that is the result of millions of lines of impeccable code.
Like all patterns, nothing is entirely new: anyone who has studied quality in industrial manufacturing is familiar with Taguchi methods. A crude metaphor for cost to society would be a pile of phones outside my window. Another I credit to Dr. Tapan Bagchi: you can manufacture a shirt to specification, and measure the quality using Six Sigma methods. But how do I know if someone will like the shirt? How can I guarantee that of all the shirts on the rack, this is the shirt I will choose to wear?
A good indicator of whether we are following the value pattern or not is to observe how we are developing and iterating. It is a question that must be asked every time we create, discuss, or present a user story. We often get confused by project constraints. Are all of our decisions informed by the value pattern?
I like to think of constraints as rocks, and patterns as water. I also do not like projects. I like products. Projects are full of rocks - deadlines, fixed costs, and dependencies that are not related to the actual value of the product. Products that add value follow the value pattern. If this pattern is not followed, the product will not add value, and the project will fail regardless of how we masterfully manipulate the constraints.
Water will wear away rock.